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dOTRO LIBRO NUEVO? 



Otro libro nuevo. Me siento casi como Cesar Vidal, aunque mas 
joven, sin becarios que escriban por mi y sin ni pretension de publicar veinte 
libros cada alio. 

Heclia la broma, tienes entre tus manos un libro que, al igual que 
sucedio con el anterior Pruebas de Rendimiento TIC, da respuesta a una 
necesidad de trabajo que ha ido creciendo y que tambien parece que puede 
ser util a mas gente. 

En esta ocasion nos hemos visto en la necesidad de formar 
profesionales TIC en la ejecucion de pruebas de seguridad, mas 
concretamente, de pruebas de evaluacion de vulnerabilidades lo mas 
sistematicas y automatizadas que sea posible, pero sin renunciar a unos 
mfnimos de calidad en los resultados. iEI objetivo? Disponer personal con 
perfiles heterogeneos que pueda desarrollar pruebas que garanticen que los 
servicios desplegados son revisados mfnimamente ante las vulnerabilidades 
mas comunes. 

Por tanto ha sido necesario formar a administradores de sistemas, 
administradores de red o desarrolladores. Personas que no pretenden ser 
expertos y que ven estas pruebas como una herramienta mas de su trabajo; 
una herramienta a usar cada cierto tiempo. En consecuencia quieren 
claridad y practicidad porque despues de la evaluacion de las 
vulnerabilidades hay que volver al quehacer diario: subir de version una 
base de datos, programar una nueva aplicacion, actualizar e\ firmware de un 
router... 

Como ya sucedio en el caso de las pruebas de rendimiento, existe 
una literatura extensa al respecto: The Art of Software Security Assessment: 
Identifying and Preventing Software Vulnerabilities, Gray Hat Hacking: The 
Ethical Hacker's Handbook, Professional Pen Testing for Web Applications, 
Advanced Penetration Testing for Highly-Secured Environments, ... 



dOtro libro nuevo? 



Sin embargo, todos vuelven a ser libros centrados en la formacion 
de expertos y de profesionales que quieran centrar sus perfiles y su 
actividad profesional en el campo de la seguridad de la informacion. Por 
tanto, todos ellos son libros con un alcance y una vision mucho mas 
profundas que las requeridas para este caso, tambien en correspondencia 
con su complejidad. 

Es decir, libros que para nuestro cometido estan en las antfpodas 
de las necesidades de la accion formativa, donde como hemos comentado 
lo que se pretende es instruir en una metodologia basica para la realizacion 
de pruebas de evaluacion de vulnerabilidades. 

Con este texto, por tanto, no se pretende ni innovar, ni tampoco 
descubrir el fuego, sino cubrir un hueco para el que no hemos encontrado 
una respuesta en el mercado. Lo mas parecido serfa Hacking for Dummies 
pero adolece de estar mas focalizado en el proceso de explotacion e 
intrusion que en el proceso de revision de vulnerabilidades. 

En definitiva, este libro pretende ser una suerte de Security Testing 
for Dummies. Esperemos haber logrado el objetivo. 

Sin mas, nuevamente y de verdad, que os sea util. 



Javier Medina. 
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GlosarioI 0 



Amenaza 

Una amenaza es toda circunstancia que tiene el potencial de causar 
dano/innpacto a un sistema de infornnacion en fornna que se compronneta su 
disponibilidad, confidencialidad, integridad, autenticidad, trazabilidad o 
capacidad de no-repudio. 

Ataques dirigidos 

Un ataque dirigido es una intrusion compleja en multiples etapas con un 
objetivo concreto. Normalmente implica un ataque inicial, seguido por la 
instalacion de software que permite mantener el acceso al sistema atacado 
y la posterior explotacion de nuevas vulnerabilidades desde ese sistema. 

Ataques Web 

Un ataque Web es toda accion maliciosa que se desencadena sobre un 
servidor web o sobre los clientes que hacen uso de este. 

Blacklisting 

La lista negra es el proceso de identificacion y bloqueo de programas, 
correos electronicos, direcciones o dominios IP conocidos maliciosos o 
malevolos. 

Botnet 

Conjunto de equipos bajo el control de un atacante a traves de un canal de 
control. Estos equipos normalmente se comercializan posteriormente a 
traves de Internet y se utilizan para actividades malintencionadas, como el 
envio de spam y ataques distribuidos de negacion de servicio. 
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Denegacion de servicio (DoS) 

La negacion de servicio es un tipo de ataque en el que el atacante intenta 
deshabilitar los recursos de una computadora o lugar en una red para los 
usuarios. 

Un ataque distribuido de denegacion de servicio (DDoS) es aquel en que el 
atacante aprovecha una red de computadoras distribuidas, conno por 
ejemplo una botnet, para ejecutar el ataque. 

Filtracion de informacion (Information disclosure) 

Una filtracion de datos es una perdida de confidencialidad derivada de un 
sistema comprometido o vulnerable que expone su informacion a un 
entorno no confiable. 

Firewall 

Un firewall es una sistenna de seguridad disenado para filtrar las conexiones 
entrantes y salientes de una red. Un firewall deberia formar parte de una 
estrategia de seguridad de multiples niveles. 

Firmas 

Una firma es un archivo que proporciona informacion al software 
automatizado de seguridad para detectar riesgos y vulnerabilidades. Esta 
tecnologia se usa en herramientas de deteccion automatizadas. 

Greylisting 

La lista gris es un metodo de defensa para proteger a los usuarios. Ante la 
deteccion de un patron no expresamente aceptado el sistema reaccionara 
rechazando la peticion durante un periodo de tiempo. Transcurrido un 
tiempo el sistema aceptara la peticion. Evita de esta manera el ataque 
automatizado. 



Evaluacion de Vulnerabilidades TIC 



Ingenieria Social 

Metodo utilizado por los atacantes para engafiar a los usuarios del sistema 
de informacion, para que realicen una accion que normalmente producira 
consecuencias negativas. 

Malware 

El malware es la descripcion general de un programa informatico que tiene 
efectos no deseados o maliciosos. Incluye virus, gusanos, troyanos y puertas 
traseras. 

Phising 

Metodo de ataque que tiene como objetivo redirigir el trafico de un sitio 
web a otro sitio falso, generalmente disefiado para imitar el sitio legitimo. El 
objetivo es que los usuarios ingresen informacion personal confiando de la 
autenticidad del sitio. 

Rootkits 

Componente de malware que se utiliza para mantener el acceso tras una 
primera intrusion. Las acciones realizadas por el rootkit, como la instalacion 
y ejecucion de codigo, se realizan sin el conocimiento o consentimiento del 
usuario afectado. 

Sistema de deteccion de intrusos (IDS) 

Un sistema de deteccion de intrusos es un servicio que monitoriza los 
eventos del sistema de informacion para encontrar y proporcionar en 
tiempo real advertencias de intentos de acceso a los recursos del sistema de 
manera no autorizada. 

Sistema de prevencion de intrusos (IPS) 

Un sistema de prevencion de intrusos es un dispositivo (hardware o 
software) que supervisa las actividades de la red o del sistema en busca de 
comportamiento no deseado o malicioso y puede reaccionar en tiempo real 
para bloquear o evitar esas actividades. 
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Vector de ataque 

Un vector de ataque es el metodo que utiliza una amenaza para atacar un 
sistema. 

Vulnerabilidad 

Una vulnerabilidad es un estado de insuficiencia en un sistema informatico 
(o conjunto de sistemas) que permite la materializacion de una amenaza 
afectando las propiedades de disponibilidad, confidencialidad, integridad, 
autenticidad, trazabilidad o no-repudio. 

Whitelisting 

La lista blanca es un metodo de autorizacion e identificacion que permite 
unicamente el uso a aquellos usuarios o direcciones IP autorizados 
expresamente para ello. 
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COMENZANDOj 1 



Empezamos con un primer capitulo donde tratar unos puntos 
basicos, que incluso pueden parecer poco importantes, pero que seran de 
utilidad en los siguientes capitulos y, lo principal, pernniten a cualquiera que 
eche un vistazo saber si es esta guia es lo que necesita o si esta buscando 
otra cosa. 



• Enfoque y destinatarios. Cual es la finalidad y para que personas 
esta pensado este texto. 

• iQue es una prueba de seguridad? Explicacion breve de que son 
este tipo de pruebas: idonde encajan?, ique es lo que se prueba?, 



• dPara que sirve una prueba de seguridad? El siguiente paso a 
conocer que son es saber para que las podemos utilizar. 

• Tipos de pruebas. Una vez que sabennos que son y para que sirven 
necesitannos saber los diferentes subtipos que existen: 18 subtipos 
diferentes, nada nnenos, que tenennos que ser capaces de distinguir 
y diferenciar. 

• Ideas adicionales. Para finalizar unas cuantas ideas adicionales que 
tratan desde conceptos que comunmente se malinterpretan a 
recomendaciones generales. 



etc. 
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1.1 I ENFOQUE YDESTINATARIOS 

Los destinatarios de este libro son profesionales en los cannpos de 
las tecnologias de la infornnacion y las connunicaciones que, sin dedicarse a 
ello a tiempo completo y sin pretenderse expertos, necesitan realizar 
evaluacion de vulnerabilidades, con un grade de automatizacion alto, sobre 
su propio sistema de infornnacion. 

Evaluacion que para un mejor resultado incluye algunas pequenas 
pruebas nnanuales y verificacion de resultados igualnnente nnanual. En 
ningun nnonnento este texto se centra en la explotacion y las herramientas a 
usar seran de acceso gratuito y, dentro de lo posible, libres. 

El enfoque de la guia, siendo consecuentes con el publico objetivo, 
es reduccionista. Es decir, lo que lees en ningun monnento quiere ser la 
biblia de eso que se llanna vulnerability assessment; sino todo lo contrario. 
Se intenta simplificar, descartar infornnacion excesiva, agrupar y 
procedimentar la realizacion de pruebas semiautomatizadas de evaluacion 
de vulnerabilidades. 

La idea es que cualquiera, incluso sin nunca haber hecho una antes, 
con un poco de esfuerzo por su parte, consiga dar respuesta a las preguntas 
mas comunes a las que una prueba de este tipo responde. 

La decision de simplificar, descartar, agrupar y procedimentar 
implica, no puede ser de otra forma, una perdida de precision y de exactitud 
en las pruebas que se realicen usando este texto como base. Usando 
metodologias mas completas y enfoques mas globales los resultados que se 
obtendran seran mas precisos. 

Sin embargo, nuestra finalidad es otra. 

Queremos obtener resultados lo suficientemente buenos como 
para que sean validos en la toma de decisiones. Y queremos que estos 
resultados puedan ser obtenidos por cualquiera profesional de los que 
conforman un area/departamentoTIC. 

Este es el enfoque de esta guia. 
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1.2 I dQUE ES UNA PRUEBA DE SEGURIDAD? 

Las pruebas de seguridad son un proceso tecnico, un conjunto de 
pruebas y verificaciones, destinado a evidenciar las deficiencias existentes 
en materia de seguridad de la informacion en un sistema TIC. 

Este tipo de pruebas consisten, por tanto, en la ejecucion de una 
serie de acciones tecnicas, mas o menos automatizadas, que nos muestra 
las insuficiencias en las principales dimensiones de la seguridad de la 
informacion para cada servicio que sea evaluado: confidencialidad, 
integridad, disponibilidad, autenticidad y no-repudio. 

Es importante puntualizar que una prueba de seguridad 
unicamente valida la existencia de vulnerabilidades, pero nunca garantiza su 
inexistencia. 

Dimensiones de la seguridad 

Aunque, poco a poco, las cinco dimensiones de la seguridad se han 
hecho de uso frecuente, y por tanto son conocidas, vamos a recordar 
brevemente a que hace referenda cada una. 

La confidencialidad es la propiedad que impide la divulgacion de 
informacion a personas o sistemas no autorizados. A grandes rasgos, 
asegura el acceso a la informacion unicamente a aquellas personas que 
cuenten con la debida autorizacion. 

La integridad, por su parte, es la propiedad que busca mantener los 
datos libres de modificaciones no autorizadas. La integridad es el mantener 
con exactitud la informacion tal cual fue generada, sin ser manipulada o 
alterada por personas o procesos no autorizados. 

La disponibilidad es la caracteristica de la informacion de 
encontrarse a disposicion de quienes deben acceder a ella, ya sean 
personas, procesos o aplicaciones. La disponibilidad es por tanto el acceso a 
la informacion y a los sistemas por personas autorizadas en el momento que 
asi lo requieran. 
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La autenticidad es la propiedad que permite identificar el 
generador de la informacion. Por ejempio al recibir un mensaje de alguien, 
estar seguro que es de ese alguien el que lo ha mandado, y no una tercera 
persona haciendose pasar por la otra. En un sistema de informacion se 
puede aceptar el uso de cuentas de usuario y contraseinas de acceso. 

Finalnnente, el no repudio proporciona proteccion contra la 
negacion, por parte de alguna de las entidades innplicadas en la 
comunicacion, de haber participado en toda o parte de la misma. 

Una idea general del proceso 

Como todo proceso, la ejecucion de una prueba de seguridad 
conlleva la ejecucion ordenada de una serie de tareas divididas en varias 
fases. 

La [figura I-I7 nnuestra los hitos habituales para la ejecucion de una 
prueba de seguridad: planificacion y diseino, ejecucion, verificacion de 
resultados y explotacion, finalnnente infornne y correccion . Este proceso 
sera explicado con detalle en el capitulo 4. 



PlanificacionI 
y Diseno 



Informe y 
Correccion 



Ejecucion, 
Verificacion y 
Explotacion 



Figura 1-1 
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dQue es lo que se prueba? 

Hemos dicho que en una prueba se buscan insuficiencias o aspectos 
de mejora en las dimensiones de la seguridad. Pero eso es algo bastante 
etereo. 

Realnnente, cuando hacemos una prueba de seguridad estamos 
evaluando las insuficiencias en tres aspectos simultaneos del servicio 
evaluado: en el propio servicio, en su configuracion y en las nnedidas de 
seguridad que se le han aplicado. 

La [figura 1-2] nnuestra la triada de elementos evaluados cuando se 
realiza una prueba de seguridad. 

Es nnuy importante entender, por tanto, que la existencia de 
vulnerabilidades estara asociada a uno de estos elennentos y que por tanto 
deberennos distinguir vulnerabilidades en el servicio, vulnerabilidades en la 
configuracion del servicio y, finalmente, vulnerabilidades en las medidas de 
seguridad que protegen al servicio evaluado. 



Servicio 



• Defectos o insuficiencias en su codificacion que permitan a 
un usuario malintencionado afectar a alguna dimension de 
la seguridad. 



Configuracion 



• Defectos o insuficiencias en la configuracion del la 
infraestructura IT que sustenta el servicio que puedan ser 
utilizadas para afectar a alguna dimension de la seguridad. 



Medidas de seguridad 



• Eficacia y madurez de las medidas de seguridad desplegadas 
para garantizar la seguridad de un servicio IT. 



Figura 1-2 
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El cicio de vida de la seguridad: ddonde encaian las pruebas? 

Las pruebas de seguridad cobran protagonismo en las fases de 
despliegue y de mantenimiento de un servicio IT. 

Sin embargo, conno muestra la [figura 2-3] debemos entender que 
la gestion de la seguridad es un proceso mas amplio que discurre paralelo a 
los proceso de gestion de entrega de servicios, y que por tanto la ejecucion 
de pruebas de seguridad debe ser una parte mas de ese proceso. 

Si no existen pollticas, normativas y medidas de seguridad de las 
que extraer requerimientos para cada entrega de servicio, sino se llevan a 
cabo implementaciones bajo metodologlas seguras, sino se protege la 
infraestructura o si no se despliegan medidas de proteccion para los nuevos 
servicios, las pruebas de seguridad no aportaran gran valor. 




Definiciony Diseno 1 


■ 

[Gest. Entrega] Requerimientos de Seguridad: 
Operativa, Autenticacion, IVledidas de Proteccion, 

1 






Implementacion 1 


[Gest. Entrega] Revision de Codigo 
[Gest. Entrega] Securizacion Infraestructura 






Despliegue 1 


r 

[Gest. Entrega] Aplicacion IVledidas Globales 
[Gest. Entrega] Evaluacion Vulnerabilidades 




Mantenimiento 1 


[Gest. Seguridad] Evaluacion Vulnerabilidades ' 
[Gest. Seguridad] Test de Intrusion 


1 



Figura 1-3 



Evaluacion de Vulnerabilidades TIC 



dQue es una vulnerabilidad? dY que es una amenaza? 

La definicion canonica de vulnerabilidad nos dice que es una 
debilidad o insuficiencia en el sistema de informacion que permite la 
materia lizacion de una amenaza, permitiendo sobrepasar, en caso de que 
existan los controles de seguridad del sistema. 

Las amenazas serfan cualquiera de los sucesos que pueden 
acontecer sobre sistema de informacion que supusiese un menoscabo en 
alguna de las dimensiones de la seguridad. Es decir, desde que un usuario 
acceda a datos de otro, a que un usuario modifique datos sin autorizacion, 
falsee informacion o deje el sistema indisponible. 



Controles 



Controles 




Activos 



Destruccion 
Denegacion 
Revelacion 
Modificacion 



FIGURA 1-4 
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^ EJEMPLO 1-1 - Vulnerabilidades 

Para intentar clarificar al maximo que es una vulnerabilidad vamos a 
usar un ejempio concrete y real de una vulnerabilidad. 

Apache HTAccess LIMIT Directive Bypass Configuration Error Weakness 

Class: Configuration Error 

Remote: Yes 

LIMIT directives are commonly used in htaccess files to restrict HTTP methods 
that are available for a particular resource. However it has been reported that if 
the requested resource is served by an Apache module and not by Apache Server 
itself, LIMIT restrictions may not apply. Additionally, CGI/Script resources that do 
not sufficiently check the calling method may potentially be invoked with 
methods not listed in the LIMIT clause to evade LIMIT restrictions. 



FtGURA 1-5 

Este es un error de configuracion en Apache. Este error de 
configuracion pernnite la evasion de un control: concretamente del 
control de la autenticacion. 

De esta fornna un atacante externo que quiera acceder de fornna no 
autorizada (la amenaza) puede evadir el proceso de autenticacion (el 
control) debido a un error de configuracion en el fichero .htaccess de 
Apache (la vulnerabilidad) accediendo a la informacion del servidor (el 
activo) y obteniendo de esa forma informacion para la que no esta 
autorizado (el impacto). 
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1.3 I (LPARA QUE SIRVE UNA PRUEBA DE SEGURIDAD? 

Una prueba de seguridad, dependiendo del tipo de prueba, mas 
adelante veremos los tipos, y del punto del cicio de vida del servicio en los 
que se realicen pruebas puede tener utilidades diversas. 

Fase de desarrollo 

■ Si es un desarrollo propio, su utilidad es la deteccion de defectos 
tempranos en la codificacion. Estas pruebas deberian ser 
complementarias a la revision de codigo. 

Fase de Preproduccion 

■ Deteccion de deficiencias y de aspectos de mejora en la 
implementacion final del servicio. 



■ Deteccion de errores en la configuracion de la infraestructura IT 
asociada al servicio. Para ello es fundamental que la infraestructura 
de preproduccion implemente las mismas configuraciones que la 
infraestructura de produccion. 

■ Establecimiento de unos requisitos mmimos de seguridad y de 
ausencia de errores previo al paso a produccion. 

Fase de Produccion 

■ Evaluacion de las medidas de proteccion global del sistema de 
informacion: IDS/IPS, cortafuegos de aplicacion, ... 

■ Verificacion de vulnerabilidades publicadas en software de S^'s 
previamente a su correccion. 

■ Cuantificacion del impacto que las diferencias de versiones entre 
los entornos de desarrollo y preproduccion pueden tener en la 
seguridad del servicio. 
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1.4 I TiPOS DE PRUEBAS 

Hasta ahora hemos hablado de pruebas de seguridad sin hacer 
distincion entre los diversos tipos que existen. Sin ennbargo, nada nnas lejos 
de la realidad, puesto que tras el concepto prueba de seguridad, en ingles 
security test, existen diversos tipos de pruebas segun los siguientes criterios: 

• Objetivo de la prueba: Segun el objetivo de la prueba se distinguen 
por un lado pruebas de evaluacion de vulnerabilidades, en ingles 
vulnerability assessement, y por otro lado las conocidas como 
pruebas de intrusion, del ingles penetrat/on testing. 

• Nivel de automatizacion: Segun el nivel de autonnatizacion usado 
en la prueba distinguimos: pruebas automatizadas, pruebas 
senniautonnatizadas y pruebas manuales. 

• Conocimiento y privilegios en el sistema de informacion: Por 

ultimo, en funcion del conocimiento y de los privilegios que se 
disponen en el sistema de informacion se diferencian: pruebas en 
caja negra, black-box testing, pruebas en caja gris, grey-box testing, 
y por ultimo pruebas en caja blanca, M//?/te-ibox testing. 

Objetivo: amplitud vs. profundldad 

En toda prueba de seguridad hay un objetivo, vamos a llamarlo 
principal o fundamental, independientemente del servicio, la tecnologia o 
cualquier otra consideracion. Un ingles diria que es el main goal. Bien, pues 
este objetivo fundamental diferencia dos tipos de pruebas: el test de 
intrusion vs. la evaluacion de vulnerabilidades. 

La evaluacion de vulnerabilidades es un tipo de prueba destinada a 
elaborar una lista lo mas amplia y completa que seamos capaces de las 
vulnerabilidades existentes en el sistema, priorizadas por nivel de impacto y 
con recomendaciones para su correccion. 
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Por contra, el test de intrusion es un tipo de prueba que tiene por 
finalidad la consecucion de un objetivo prefijado con anterioridad, como 
puede ser conseguir privilegios de superusuario en el SGBD, acceso a la red 
interna de servicios o a la red de gestion de infraestructura IT (en caso de no 
fijarse objetivo, se entiende que la finalidad es la obtencion del mayor nivel 
de privilegio posible). El resultado de un test de intrusion, en consecuencia, 
es la identificacion y explotacion de una o varias vulnerabilidades que de 
forma encadenada consiguen elevar nuestro nivel de privilegios en el 
sistema hasta la consecucion del objetivo fijado. 

La [figura 1-4] ilustra la diferencia entre estas dos tipologlas de 

prueba. 

/ \ 

Testde intrusion 

s ^ 




/ \ 

Evaluacion de 
vulnerabilidades 




Figura 1-6 

Es importante entender, que aunque en el test de intrusion se 
identifiquen vulnerabilidades como paso previo a su explotacion y a la 
elevacion de privilegios en el sistema, y aunque muchas veces se ejecute 
una revision sistematica de vulnerabilidades, en el momento que se 
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encuentre la vulnerabilidad deseada que nos permite elevar nuestros 
privilegios, no es necesario continuar con el proceso de identificacion de 
vulnerabilidades. 

En el piano mas practico del asunto la evaluacion de 
vulnerabilidades es un proceso que nnuestra su utilidad en organizaciones 
con una madurez en la gestion de la seguridad de la informacion media-baja 
donde, a priori, sabemos que existen vulnerabilidades y queremos 
identificarlas y obtener una vision general del estado del sistema de 
informacion. 

Por contra, el test de intrusion es un proceso recomendado para 
organizaciones con un nivel de gestion de la seguridad medio-alto, donde lo 
que se busca es evaluar la efectividad del proceso de gestion de la seguridad 
y de las medidas de proteccion desplegadas en el sistema de informacion. 



La [figura 1-5] recoge un resumen de los puntos fundamentales 
que diferencian ambas tipologias de pruebas. 





Eval. Vulnerabilidades 


Test de Intrusion 


Objetivo 




Obtencion privilegios 


Resultado 




Subconjunto vulnerabilidades 


Clave 




Profundidad 


Recomendado 


Seguridad media-baja 


Seguridad media-alta 



Figura 1-7 



Nivel de automatizacion 

El nivel de automatizacion hace referenda al nivel de uso de 
tecnicas manuales en el proceso de identificacion y explotacion de 
vulnerabilidades. 

Es decir, se parte de la base de que todas las pruebas hacen uso de 
herramientas automatizadas para simplificar algunos procesos (recopilacion 
de informacion, identificacion, explotacion...) y, a partir de esta base, se van 
afiadiendo capas de trabajo manual a la prueba como se puede ver en la 
[figura 1-6]. Es decir, una prueba manual, de forma comun, incluye las 
tareas de las pruebas semi-automatizadas y automatizadas. 
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Pruebas automatizadas: Son aquellas que unicamente hacen uso 
de herramientas para la ejecucion de la prueba. Este tipo de 
pruebas presentan una eficacia pobre, un nivel de ruido nnuy 
elevado y una utilidad bastante linnitada. Poco recomendables. 

Pruebas semiautomatizadas: Las pruebas semiautomatizadas son 
el siguiente nivel de nnadurez de una prueba de seguridad. En este 
tipo de pruebas, generalmente a partir de la informacion obtenida 
por las herrannientas automatizadas, se desarrolla un trabajo 
nnanual de verificacion de resultados y descarte de falsos positivos. 
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En los niveles mas completos de la semiautomatizacion se pueden 
incluir algunas tareas manuales para completar aquellas funciones 
que las herramientas automaticas no cubren de forma precisa. 

Pruebas manuales: En este tipo de pruebas, ademas de realizar las 
tareas de la revision semiautomatizada como una aproximacion 
rapida se Neva a cabo, de forma paralela y mediante el uso de 
herramientas manuales, una revision sistematizada y exhaustiva de 
vulnerabilidades. Es muy comun que esta revision se realice en base 
a metodologia concreta de auditoria como puede ser ISSAF, OWASP 
u otras. 

Conocimiento v privilegios 

Por ultimo, en funcion del nivel de conocimiento sobre el sistema 
de informacion y del nivel de privilegios, se diferencian tres tipos de 
enfoque: caja negra, caja gris y caja blanca. 

La evaluacion en caja negra Simula a un atacante externo, sin 
conocimiento de la implementacion del sistema informacion, sin 
credenciales de acceso y que unicamente puede verificar la E/S del sistema 
de informacion. 

La evaluacion en caja blanca por contra es una revision en la que se 
actua como personal IT que tiene un conocimiento detallado y completo del 
sistema de informacion, que cuenta con credenciales de acceso al sistema, 
que puede revisar si existe el codigo fuente, que dispone de acceso 
completo a logs, ... 

Por ultimo, a medio camino entre ambas aproximaciones esta lo 
que se conoce como revision en caja gris donde se dan caracteristicas de 
ambos entornos: el conocimiento del sistema es elemental, no se conocen 
detalles concretos de implementacion, no se dispone de codigo fuente, en 
caso de tenerlo se dispone de un acceso basico al sistema, sin privilegios 
administrativos y, en el mejor de los casos, se dispone de acceso a los logs 
del sistema. 

La [figura 1-9] resume las tres tipologias comentadas. 
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Caja Negra 



Caja Gris 



Caja Blanca 



• Atacante externo 

• Sin conocimiento 

• Sin credenciales 

• Basado totalmente en 
informacion de E/S 



• Usuario de la 
organizacion. 

• Conocimiento basico 
del sistema de 
informacion. 

• Detalles concretos de 
implementacion no 
conocidos. 

• Opcional: acceso 
basico sin privilegios 
en el sistema. 

• Opcional: logs. 



• Personal IT. 

• Conocimiento 
detallado del sistema 

• Credenciales de 
acceso de usuario 

• Acceso a codigo 
fuente, logs, ... 
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Conclusion 

Como hemos visto el concepto de prueba de seguridad se divide 
realmente en 18 subtipos de pruebas distintos, segun los 3 parametros que 
hemos comentado. La [figura 1-10] resume y sintetiza estas subdivisiones. 



Objetivo 



Automatizacion 



Evaluacion 
Vulnerabilidades 



— Prueba Intrusion 



Automatizada 



Semi- 
Automatizada 



Manual 



Conocimiento 
y Privilegios 



Figura 1-10 
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1.5 I Ideas ADiciONALES 

No hay varitas magicas 

Puede ser tentador imaginar que existe un determinado software, 
que aunque sea muy costoso, es capaz de pulsando un boton realizar una 
evaluacion autonnatizada de la seguridad del sistenna de informacion y 
proporcionarnos un informe detallado del estado del sistenna. 

Sin embargo, desengafiate, eso no existe. dEI software 
automatizado de evaluacion de vulnerabilidades es util? Sf. <LEI software 
automatizado de evaluacion de vulnerabilidades ayuda y simplifica el 
trabajo? Sf. Pero no mas. Las herramientas automatizadas deben ser vistas 
como el primer paso para obtener una revision rapida y sistematica de las 
vulnerabilidades mas evidentes, pero en la amplia mayoria de situaciones 
sera un resultado incompleto. 

En general, las herramientas automatizadas responden 
aceptablemente a la identificacion de vulnerabilidades derivadas de 
insuficiencias en la validacion de la entrada de usuario: XSS, SQLinjection, 
etc. Asi como a la deteccion de errores de configuracion. 

Sin embargo, su respuesta es mucho menos satisfactoria en las 
vulnerabilidades derivadas de errores en la logica del aplicativo y de 
insuficiencias en los procesos de autenticacion y, sobre todo, de 
autorizacion. 

A vueltas con los usuarios y modelo de capas 

En los tiempo que corren, donde la evolucion hacia sistemas cuya 
interaccion con el usuario es "100% web" avanza imparable, ha hecho que 
en consecuencia la revision de la seguridad del sistema de informacion se 
focalice, primordialmente, en la web. 

No obstante, aunque esto puede ser mas o menos acertado para 
usuarios externos del sistema, los cuales es posible que mayoritariamente 
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interactuen con servicios web, los usuarios internes cuentan con acceso a 
otras nnuchas capas. 

Un usuario interne de la organizacion contara con acceso a la capa 
de red, y a otros servicios internos: directorio activo, recursos de red 
connpartidos, etc. 

Por tanto, a la hora de plantear pruebas de seguridad, debemos 
tener muy en cuenta que tipo de usuario querennos simular y por tanto que 
servicios debennos evaluar. 

Es un error pensar que la web lo es todo. La web es muy 
innportante, cierto. La web es el servicio mas expuesto, cierto. 

Pero un atacante, si encuentra una web diflcilmente vulnerable, no 
va a tener problemas en buscar otro servicio menos costoso de vulnerar. 



Usuarios externos 



Usuarios Internos 



• Servicios Web Publicos 

• Servicio DNS 

• Servicio Correo 



• Servicios Web Publicos 

• Servicios Web Privados 

• Servicio DNS 

• Servicio Correo 

• Servicio Ficlieros 

• Servicio Directorio 

• Servicio Red Interna 

• Servicio Red WIFI 

• Servicio VoIP 

• Servicio VPN 

• Servicio ... 
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Despues de la introduccion a las generalidades del proceso, en este 
segundo capftulo toca analizar el conjunto de vulnerabilidades nnas 
connunes que podemos encontrar en un sistema de informacion. 

Para la catalogacion hemos utilizado una mezcla de las 
metodologfas OWASP e ISSAF, sin embargo, ninguna catalogacion es 
perfecta y en algunos casos la categorfa padre podrfa ser discutible. 

No obstante, para nuestro proposito, la catalogacion no debe 
quitarnos el sueno. Si fuesemos a vender nuestros servicios quiza tuviese 
mas importancia. Pero en el ambito interno nadie va a pelear por si un una 
vulnerabilidad CSRF es un error de autenticacion o de autorizacion. 

Lo prioritario debe ser entender cada una de las vulnerabilidades 
expuestas, conocer cual es la efectividad de las suites automatizadas en la 
deteccion de cada una, conocer como podemos verificar su existencia de 
forma manual, y en caso de que exista la vulnerabilidad saber cual es la 
recomendacion general para su correccion. 

Ni que decir tiene que este capitulo es fundamental para poder 
continuar avanzando en el libro. Por ello se recomienda una lectura pausada 
y la investigacion personal de aquellas vulnerabilidades que no terminen de 
quedar claras. 

Los contenidos que se veran en el capitulo son los siguientes: 

• Vulnerabilidades en la configuracion. A este tipo de errores 
corresponden los que se presentan por configuraciones deficientes 
de la infraestructura IT, tanto web, como no web. 

• Vulnerabilidades en la logica de negocio. La logica de negocio es la 
posibilidad por parte del usuario de realizar acciones que van en 
contra de las especificaciones funcionales del servicio o aplicativo. 
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• Vulnerabilidades en la autenticacion. Las vulnerabilidades en la 
autenticacion recogen todas aquellas deficiencias que pueden 
pernnitir a un usuario el acceso no autorizado a la aplicacion 
suplantando la identidad de otro usuario. 

• Vulnerabilidades en la autorizacion. Las vulnerabilidades de 
autorizacion son aquellas que permiten a un usuario realizar 
acciones que estan por encima de su nivel de privilegio. 

• Vulnerabilidades en la validacion. Las vulnerabilidades de 
validacion corresponden, sin duda, al mas amplio de todos los 
grupo de vulnerabilidades, en el se recogen todas aquellas 
vulnerabilidades que se producen a partir de la nnalformacion de las 
peticiones que provienen del usuario y que tienen conno 
consecuencia el impacto sobre algunas de las dimensiones de la 
seguridad. 

• Tabia Resumen. Donde se repasaran todas las vulnerabilidades y la 
utilidad de los nnecanismos autonnatizados en la deteccion de las 
mismas. 
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2.1 I Vulnerabilidades EN la configuracion 

La evaluacion de la infraestructura que sustenta los servicios y 
aplicativos mostrara los errores de configuracion que impactan en las 
dimensiones de la seguridad de la informacion. 

Errores configuracion SSL 

• Descripcion: SSL y TLS son dos protocolos que proporcionan 
canales seguros para la proteccion de la confidencialidad y la 
autenticidad sobre la informacion transmitida. 

Esta prueba verifica la utilizacion de algoritmos de cifrado 
robustos y considerados seguros. A efectos practicos se 
consideraran cifrados robustos todos los equivalentes a TLS 1.1 
o superior con uso de clave privada AES128 y funcion de 
hashing SHAl. Ademas, se verificara que no se permite la 
conexion con algoritmos considerados inseguros. 

• Suite automatizada: Si. Esta prueba se encuentra incluida en 
los escaneres de vulnerabilidades de servicios de red mas 
comunes: OpenVAS, Nessus o Nexpose. 

• Verificacion IVIanual: Manualmente se puede realizar la 
verificacion mediante el uso del comando openssi o mediante 
el uso del script testssl.sh (https://testssl.sh/) 

• Correcclon: En case de existir esta vulnerabilidad la 
recomendacion es inhabilitar en la configuracion las 
implementaciones de SSL consideradas vulnerables. 
Recomendandose en aquellos casos que sea posible el uso de 
TLS1.2 
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^ EJEMPLO 2-1 - Conexion forzada mediante SSLv2 



El siguiente ejempio muestra el uso del comando openssi para 
establecer una conexion mediante SSLv2 a un servicio. 



En este caso el servicio rechaza la conexion mediante el protocolo 
inseguro SSLv2. 



$ openssi s_client -no_tlsl_l -no_tlsl_2 -no_tlsl -no_ssl3 -connect 
server: 443 



CONNECTED(00000003) 
139690903496384 : error : 14077102 : SS L 

routines : SSL23_GET_SERVER_HELLO: unsupported protocol : s23_clnt . c : 714: 

no peer certificate available 

No client certificate CA names sent 

SSL handshake has read 7 bytes and written 225 bytes 

New, (NONE), Cipher is (NONE) 
Secure Renegotiation IS NOT supported 
Compression: NONE 
Expansion: NONE 



FIGURA 2-1 

Errores configuracion DB Listener 

• Descripcion: El Listener de Oracle es un proceso que actua como 
servicio de red esperando las peticiones desde clientes remotos. 
Una incorrecta configuracion puede permitir desde denegaciones 
de servicio, enumeracion de informacion o en el peor de los casos 
accesos no autorizados a la base de datos. 



El receptor Oracle escucha en los puertos 1521, 2483 y 2484 
dependiendo de la configuracion de Oracle. 
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• Suite automatizada: Si. Esta prueba se encuentra incluida en los 
escaneres de vulnerabilidades de servicios de red mas comunes: 
OpenVAS, Nessus o Nexpose. 

• Verificacion Manual: Manualmente puede ser verificado mediante 
el uso de nmap y el proceso LSNRCTL disponible en las instalaciones 
cliente de Oracle. 

• Correccion: Se recomienda seguir la guia de proteccion propuesta 
por Oracle, garantizando la existencia de una password robusta en 
el acceso al listener, asi como limitar su exposicion a ataques 
externos. En Oraclellg la autenticacion ha pasado a ser delegada al 
SO. 

^ EJEMPLO 2-2 - Uso de NMAP para obtener SID Oracle 

El ejempio muestra el uso de nmap y del script oracle-sid-brute para 
realizar un ataque por fuerza bruta y el descubrimiento del SID de la 
base de datos aprovechando la existencia de un listener inseguro. 

nmap --script oracle-sid-brute --script-args oraclesids=sids.txt -sV - 
pl521 192.168.1.25 

Nmap scan report for 192.168.1.25 (192.0.1.25) 

PORT STATE SERVICE VERSION 

1555/tcp open oracle-tns Oracle TNS Listener 

I oracle-sid-brute: 

|_ ORADB 

FIGURA 2-2 

Errores en la configuracion de la Infraestructura web v no-web 
Informacion de depuracion o de versiones 

• Descripcion: La existencia de trazas de depuracion o excesiva 
informacion de versiones puede ser entendida como una fuga de 
informacion que puede facilitar al atacante el acceso no autorizado 
al sistema. 
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Esta prueba requiere de la revision de las respuestas en texto piano 
(RAW) sin interpretar por clientes intermedios ofrecidas por el 
servicio. En el caso de servicios HTTP identificaremos cabeceras u 
otros fragmentos de informacion. 

• Automatizacion: Si. Esta prueba se encuentra incluida de forma 
comun en multitud de herramientas automatizadas, tanto web 
como no web. 

• Verificacion Manual: Su ejecucion manual requiere, en el caso web, 
del uso de un proxy de auditorfa y en el caso no-web de 
comunicacion directa con el servicio (nc/telnet/etc). 

• Correccion: Todo servicio en produccion debe eliminar la 
informacion de depuracion y la excesiva informacion sobre 
versionado. Las configuraciones de los servicios, habitualmente, 
tienen parametros para limitar este tipo de informacion. 

^ EJEMPLO 2-3 - Informacion de errores 

El ejempio recoge un caso frecuente en configuraciones incorrectas 
de PHP donde se muestra, como parte de la pagina web recibida, 
informacion de errores y avisos. 

Warning: fopen(f ichero.txt) [function .fopen] : failed to open stream: No 
such file or directory in /home/.../ejemplo.php on line 2 

FtGURA 2-3 

Servicios desactualizados y vulnerables 

• Descripcion: La existencia de servicios desactualizados permite el 
aprovechamiento de vulnerabilidades publicas por parte de 
atacantes. 

Esta prueba requiere de la revision de las respuestas en texto piano 
(RAW) sin interpretar por clientes intermedios ofrecidas por el 
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servicio. En el caso de servicios HTTP identificaremos cabeceras, 
comentarios HTML u otros fragmentos de informacion anomala. 

• Suite automatizada: Parcial. Esta prueba se encuentra incluida de 
forma comun en multitud de herramientas automatizadas, tanto 
web como no web. Se recuerda, no obstante, que numerosos 
fabricantes, principalmente de distribuciones Linux, aplican parches 
de seguridad sobre versiones que no tiene por que ser la ultima 
version existente del producto. Por tanto, a la hora de emitir 
valoracion se recomienda verificar el nivel de parcheo del sistema. 

• Verificacion Manual: Su ejecucion manual requiere, en el caso web, 
del use de un proxy de auditoria y en el caso no-web de 
comunicacion directa con el servicio (nc/telnet/etc). 

• Correccion: La medida de correccion, en caso de confirmarse la 
falta de actualizacion de seguridad, es la actualizacion del servicio a 
la version corregida. 

^ EJEMPLO 2-4 - Informacion de versiones 



El ejempio muestra el uso de un proxy de auditoria para identificar 
las versiones proporcionadas por la cabecera Server en un servicio 
web Apache. 



Nombre de cabecera recibida 


Valor de cabecera redblda 


Stahjs 


OK - 200 


Date 


Wed, 02 Jul 2008 08:11:38 GMT 


Server 


Apache/2.2.6 (Unix) mod_ssl/2.2.6 Open5SL/0.9.8F DAV/2 PHP/5.2.5 


X-Powered-By 


PHP/5.2.5 


Keep-Alive 


tlmeo(Jt-15, max»100 


Connection 


Keep-AKve 


Transfer-Encoding 


chunked 


Content-Type 


text/html 



FIGURA 2-4 
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Herramientas de admon. accesibles 



• Descripcion: La existencia de herramientas de administracion 
accesibles de forma general puede permitir a un atacante ampliar 
sus posibilidades de explotacion: vulnerabilidades conocidas, 
usuarios debiles, ... 



Esta prueba requiere del uso de fuerza bruta para realizar el 
descubrimiento de los puertos o de las ubicaciones donde se 
encuentran instaladas las herramientas administrativas. 



• Suite automatizada: Si, pero con resultado no determinista. Esta 
prueba se encuentra incluida de forma comun en multitud de 
herramientas automatizadas, tanto web como no web. 



• Verificacion Manual: En el caso de servicios de red se utilizara 
nmap para la identificacion de puertos y servicios. En el caso de 
servicios web se puede hacer uso de nikto/wikto u otro sistema de 
crawling que permita ataques hibridos a rutas conocidas y 
permutaciones de las mismas por fuerza bruta. 

• Correccion: Las herramientas administrativas deben tener limitado 
su acceso y visibilidad. Por tanto se recomienda filtrar desde que 
direcciones IP son accesibles e implementar mecanismos de 
autenticacion HTTP que impidan el acceso directo a las mismas. 



NovelL Open Enterprise Server 

SuSE Linux Entsrpriss Server 9 



□ Software de usuai io finAl 

^ Novell ePirectorv 8.7 
[n IFolder 
f^ 1Folder3 



Sj^ IvIetStoraee de Movelli 



^ QuickFinder A.O 



S Codigo abiei to 
p Gestion de i ed 



Novell NetStoi age 



ACCESO SEGURO A ARCHIVOS BAEADO EH LA WEB 

Novell NetStorage proporciona la solucion para un acceso sencillo 
basado en Internet al almacenamiento de archives. NetStorage es 
un puente entre la red de almacenamiento Novell protegida de la 
empresa e Internet. Permite que los usuarios tengan acceso seguro 
a los archives desde cualquier ubicacion en Internet, sin tener que 
descargar ni instalar ningun elemento en su estacidn de trabajo 



Oocumentacidn en Ifnea 
Abrir Netstoraae 



Funciorkes de NetStorage 

Entre las funciones clave, se incluyen; 
• ftcceso 3 archives basado en 
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Errores en la configuracion de servicios web 
Archives y funcionalidades de ejempio 

• Descripcion: La existencia de archives y funcionalidades de ejempio 
de forma generai puede permitir a un atacante ampiiar sus 
posibilidades de explotacion: vulnerabilidades conocidas, ejemplos 
inseguros, ... 

Esta prueba requiere del uso de fuerza bruta para realizar el de las 
ubicaciones donde se encuentran instalados los ficheros de 
ejempio. El exito es variable en funcion de lo comun de las rutas 
usadas. 

• Suite automatizada: Si, pero con resultado no determinista. La 
prueba se encuentra incluida de forma comun en multitud de 
herramientas automatizadas de analisis web: w3af, skipfish, vega, 
etc. 

• Verificacion Manual: Se puede hacer uso de nikto/wikto u otro 
sistema de crawling que permita ataques hfbridos a rutas conocidas 
y permutaciones de las mismas por fuerza bruta. 

• Correction: La recomendacion general es la eliminacion de 
cualquier archivo o funcionalidad de ejempio existente en los 
aplicativos web. 

Comentarios y otra informacion sensible 

• Descripcion: La existencia de comentarios con cualquier tipo de 
informacion sensible (ip's, nombres de usuario, identificadores 
numericos, ...) en el codigo no ejecutable de los aplicativos web 
puede ser entendida como una fuga de informacion que puede 
facilitar al atacante el acceso no autorizado al sistema. 

Esta prueba requiere de la revision de las respuestas en texto piano 
(RAW) sin interpretar por el navegador. 
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• Suite automatizada: Si. La prueba se encuentra incluida de forma 
comun en multitud de herramientas automatizadas de analisis web: 
w3af, skipfish, vega, etc. 

• Verificacion Manual: Su ejecucion manual requiere, en el caso 
web, del uso de un proxy de auditoria o de la comprobacion del 
codigo HTML devuelto por cada peticion en el navegador. 

• Correccion: Se recomienda limitar la informacion proporcionada en 
comentarios. En Imeas generales se recomienda la eliminacion de 
comentarios de las versiones de produccion de los aplicativos. En 
caso de no ser posible, se recomienda suprimir cualquier referenda 
a direcciones ip, nombres de usuario, sistemas de autenticacion, 
etc. 

Archives obsoletos o versiones bacl<up. 

• Descripcion: La existencia de versiones de backup o de versiones 
obsoletas de ficheros puede permitir a un atacante el acceso a 
informacion no autorizada o el aprovechamiento de 
vulnerabilidades ya parcheadas. 

Esta prueba requiere del uso de fuerza bruta sobre extensiones de 
fichero para realizar el descubrimiento de nombres de ruta 
alternativos a los conocidos donde se localicen los archivos 
antiguos. 

• Suite automatizada: Si, pero con resultado no determinista. La 
prueba se encuentra incluida con mayor o menor alcance en 
multitud de herramientas automatizadas de analisis web: w3af, 
skipfish, vega, etc. 

• Verificacion Manual: Se puede hacer uso de nikto/wikto u otro 
sistema de crawling que permita ataques hibridos a rutas conocidas 
y permutaciones de las mismas por fuerza bruta. 
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• Correccion: La recomendacion general es la eliminacion de 
cualquier fichero de backup u otros archives obsoletos del sistema 
de produccion. 

^ EJEMPLO 2-5 - Ficheros de backup 

El ejempio muestra el uso de socat para verificar la existencia de un 
fichero de backup. 

~# socat - SSL: 192. 168.1. 25 :443,verify=0 
HEAD /cgi - bin/postman. bak HTTP/1.0 

Host: myhost. local 

HTTP/1.1 200 OK 

Date: Thu, 19 Dun 2008 19:40:29 GMT 
Server: Apache 
Pragma: no-cache 

FIGURA 2-6 

Acceso a ficheros con extensiones no-web. 

• Descripcion: La existencia de ficheros con extensiones fuera de las 
habituales en la navegacion web (html, php, jsp, asp, ...) puede 
innplicar la existencia de fugas de informacion. 

Esta prueba requiere del uso de fuerza bruta sobre nonnbres y 
extensiones de fichero para realizar el descubrimiento de su 
existencia. 

• Suite automatizada: Parcial. Esta prueba puede formar parte por 
defecto de la fase de spidering de herramientas automatizadas de 
evaluacion de vulnerabilidades. 

• Verificacion IVIanual: Se puede hacer uso de nikto/wikto u otro 
sistema de crawling que permita ataques hfbridos a rutas conocidas 
y permutaciones de las mismas por fuerza bruta. 

• Correccion: La recomendacion general es la eliminacion de 
cualquier fichero innecesario del servidor web. Asi mismo se 
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recomienda limitar el acceso a cualquier extension de fichero que 
se pueda considerar potencialnnente capaz de contener 
informacion sensible (.inc, .bak, .old, ...) 

Indexacion de directorios 

• Descripcion: La indexacion de directorios permite el acceso a todo 
el contenido bajo un determinado directorio del arbol web, 
pernnitiendo a un atacante el acceso a infornnacion sensible, asi 
conno a controladores y otros elennentos del aplicativo. 

• Suite automatizada: Si. Esta prueba esta incluida en la mayorla de 
herramientas automatizadas de evaluacion de vulnerabilidades 
web. 

• Verificacion Manual: La ejecucion manual de la prueba unicamente 
requiere de acceso a un navegador. No obstante, el uso de 
mecanisnnos de fuerza bruta o de listas de nonnbres connunes de 
directorio, puede permitir el descubrimiento de directorios no 
publicos. 

• Correccion: Se recomienda, por defecto, inhabilitar la indexacion de 
directorio en los servicios web. Unicamente se habilitara para 
aquellos directorios que, por su utilidad, lo demanden. 

^ EJEMPLO 2-6 - Indexacion de directorios 

El ejempio muestra el caso de un directorio indexable en Apache. 



Index of /v2/sitio/nbproject/pri\ ate 

• Pai-ent Difectory 

• pfivate,proD«ties 



FiGURA 2-7 
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Control de metodos HTTP 

• Descripcion: La navegacion web, de forma general hace uso de los 
metodos GET y POST del protocolo HTTP. La existencia de otros 
metodos puede derivar en la construccion de ataques mas o menos 
sofisticados que pueden permitir, en el peor de los casos, el acceso 
no autorizado a recursos. 

Concretamente, en caso de que existan zonas de acceso restringido 
a determinados metodos HTTP se debe verificar que la limitacion es 
correcta y efectiva, no permitiendose el acceso a metodos no 
deseados. 

Asi mismo se debe extremar la precaucion del uso del metodos 
asociados a DAV, como por ejempio PUT. Controlando los usuarios 
desde los que se tiene acceso y las zonas donde es posible escribir. 

• Suite automatizada: No muy comun. Este tipo de vulnerabilidades 
estan incluidas parcialmente en algunas herramientas 
automatizadas como, por ejempio, w3af. 

• Verificacion Manual: La ejecucion manual de la prueba se realiza 
mediante comunicacion directa con el servidor web mediante el 
uso de nc/telnet. 

• Correccion: Se recomienda el filtrado de metodos distintos a GET y 
POST, asi como la correcta configuracion de las directivas de control 
de acceso a servicios web. 

^ EJEMPLO 2-7 - Metodos HTTP 

El ejempio muestra el uso incorrecto de la directiva LIMIT en un 
fichero htaccess de Apache, limitando el acceso unicamente a 
metodos GET, lo que permite el uso de otros metodos y la evasion 
del control de acceso. 
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$ cat .htaccess 
AuthType Basic 
AuthName Private 

AuthUserFile /etc/httpd/pass/private 
<LIMIT GET> 
require valid-user 
</LIMIT> 

$ telnet localhost 80 
GET /private/index. html HTTP/1.0 
HTTP/1.1 401 Authorization Required 
POST /private/index. html HTTP/1.0 
HTTP/1.1 200 OK 

<html><head></head><body>iNo deberias ver esto! </body></html> 

FIGURA 2-8 
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2.2 I Vulnerabilidades en la logica de negocio 

La logica de negocio en un aplicativo agrupa dos conceptos: 

• Regies funcionales de la aplicacion que expresan las 
situaciones que son aceptables (P.ej. no permitir la 
existencia de productos con valor 0 o no permitir la reserva 
de algo que ya se encuentra reservado). 

• Flujos de trabajo en el aplicativo que representan un 
conjunto de tareas ordenadas (P.ej. un proceso de compra 
debe pasar por un conjunto obligatorio de pasos: creacion 
del pedido, la obtencion de datos personales, el pago del 
pedido y la finalizacion de la orden de compra). 

• Descripcion: Las vulnerabilidades en la logica de negocio implican la 
posibilidad de alterar estas reglas o estos flujos de trabajo en 
beneficio del atacante. 

• Suite automatizada: No. Este tipo de vulnerabilidad no pueden ser 
detectada mediante analisis automatizado. 

• Verificacion Manual: Variable para cada situacion. Como ejempio 
de este tipo de vulnerabilidades en la [figura 2-9] se muestra un 
ejempio de aplicacion de reserva donde el usuario ha conseguido 
evadir el Ifmite de prestamos maximo, llegando a una situacion 
incongruente: tiene 3 objetos en prestamo de siendo el maximo 2. 

• Correccion: Variable para cada situacion. 
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^ EJEMPLO 2-8 - Errores en la logica de negocio 

El ejempio muestra el caso de una aplicacion real de prestamo 
electronico de libros evaluada hace un tiempo donde era posible 
alterar la logica de negocio llevando a la aplicacion a situaciones 
como las que muestra la [figura 2-9]. 

En ella se ve una situacion incoherente: el limite de prestanno habia 
sido sobrepasado; y la aplicacion ante la reserva normal de un 
nuevo libro informaba de que disponlamos de 3 libros en prestamo 
sobre un limite de 2. 
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2.3 I Vulnerabilidades EN la autenticacion 

Las vulnerabilidades en la autenticacion son aquellas que pueden 
permitir bajo determinadas circunstancias a un usuario malintencionado el 
acceso al servicio sin poseer unas credenciales de acceso validas. 

Transmision de credenciales por canal cifrado 

• Descripcion: El envfo de credenciales de autenticacion mediante el 
uso de protocolo en texto piano HTTP puede permitir a cualquier 
atacante que escuche en el canal de comunicacion (p.ej. redes 
wireless publicas) el acceso a las credenciales de usuario. 



• Suite automatizada: Sf. Esta prueba esta incluida en la mayorfa de 
herramientas automatizadas de evaluacion de vulnerabilidades. 



• Verificacion Manual: La ejecucion manual de la prueba requiere de 
la conexion al servicio y de la verificacion mediante un canal cifrado 
de las credenciales. Una herramienta uniforme para la verificacion 
puede ser Wireshark mediante la captura del trafico saliente y la 
comprobacion de la existencia o no de credenciales en el. 

• Correccion: La recomendacion general es que, siempre que se 
pueda, toda la comunicacion con el usuario (y no solo el envfo de 
credenciales) se realice mediante el uso de un canal cifrado. 

Posibilidad de enumeracion de usuarios 

• Descripcion: La respuesta proporcionada por los servicios, tanto 
web, como no web, puede servir para identificar la existencia de 
usuarios en el sistema siempre que exista algun tipo de patron 
logico que diferencie la respuesta. 

El mas evidente es que ante un usuario que existe muestre un 
mensaje de tipo contraseha incorrecta, mientras que ante un 
usuario que no existe muestre un mensaje de tipo usuario 
incorrecto. 
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Esta prueba requiere del uso de fuerza bruta para la enumeracion 
de usuarios en base a la existencia de listas de los mismos y a 
posibles permutaciones o variaciones sobre sus nombres. 

• Suite automatizada: No es frecuente encontrar esta prueba 
incluida en las herramientas de analisis de vulnerabilidades mas 
comunes. 

• Verificacion Manual: Inicialmente se requiere la evaluacion manual 
de la respuesta del servicio para identificar la existencia de posibles 
diferencias logicas en la respuesta. Se recomienda el uso de un 
servicio proxy de auditoria en el caso web y de conexion directa al 
servicio en otros casos. 

Para la explotacion efectiva es necesario del uso de herramientas 
especfficas como THC Hydra que permiten proceso de 
autenticacion masivos. 

• Correccion: La recomendacion general es unicamente mostrar un 
mensaje generico cuando se produzcan errores en el proceso de 
autenticacion. 

Usuarios por defecto 

• Descripcion: La existencia de usuarios por defecto puede facilitar a 
los atacantes desde informacion sobre la existencia de una cuenta a 
acceso con diferentes grades de privilegio al sistema en caso de que 
ademas del usuario por defecto se mantenga la contraserna por 
defecto. 

• Suite automatizada: No es frecuente encontrar esta prueba por 
defecto incluida en las herramientas de analisis de vulnerabilidades 
mas comunes. Algunas herramientas permiten su configuracion 
especffica para hacer pruebas de autenticacion con usuarios por 
defecto. 
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• Verificacion Manual: Se requiere hacer uso de herramientas como 
THC Hydra o Brutus para la verificacion de listas de usuarios 
conocidas. 

• Correccion: La recomendacion general es inhabilitar los usuarios 
por defecto no permitiendo el acceso con ellos y crear cuentas 
administrativas adicionales con identificadores no conocidos en el 
sistema. 

Autenticacion por f uerza bruta 

• Descripcion: La inexistencia de Knnites en el proceso de 
autenticacion, permitiendo ser repetido tantas veces el usuario 
desee y sin limitacion de tiempo entre pruebas puede facilitar los 
ataques por fuerza bruta al sistema. 

Otra variante es el uso de una unica contrasefia de acceso sobre un 
conjunto amplio de usuarios. 

• Suite automatizada: No es frecuente encontrar esta prueba por 
defecto incluida en las herramientas de analisis de vulnerabilidades 
mas comunes. Algunas herramientas permiten su configuracion 
especifica para hacer pruebas de autenticacion por fuerza bruta. 

• Verificacion Manual: Se requiere hacer uso de herramientas como 
THC Hydra o Brutus para la prueba de autenticacion por fuerza 
bruta. 

• Correccion: La recomendacion general es no permitir mas de un 
numero de procesos de autenticacion erroneos en un periodo de 
tiempo. Adicionalmente no debe permitir mas de un numero de 
procesos de autenticacion erroneos, independientemente del 
usuario, desde una IP dada. 
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Evasion del proceso de autenticacion 

• Descripcion: La evasion del proceso de autenticacion es un error 
que se produce de forma indirecta a partir de la existencia de otros 
errores: 

o Deficiencias en el proceso de autorizacion (peticion directa) 
o Falta de validacion de parametros (SQLi, LDAPi, ...) 
o Gestion incorrecta de sesion (id o parannetros predecibles, 
...) 

• Suite automatizada: No. Esta prueba es consecuencia de la 
existencia de otras vulnerabilidades previas. 

• Verificacion IVIanual: Variable en funcion del error que habilite la 
evasion del proceso de autenticacion. 

• Correccion: Variable en funcion del error que habilite la evasion del 
proceso de autenticacion. 

^ EJEMPLO 2-9 - Identificadores de sesion debiles 

El ejennpio nnuestra el caso de una aplicacion donde la generacion 
del ID de sesion es predecible debido a que no se usa un PRNG 
(generador de numeros aleatorios) robusto, sino una algoritmo 
debil. 

Un analisis de varios identificadores de sesion permite, por tanto, 
ser capaces de predecir tanto los anteriormente generados, como 
los que se generaran posteriormente. 

En caso de que el identificador de sesion sea el unico mecanismo de 
control de sesion, esto llevara a la posibilidad de suplantacion de 
usuarios. 
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Deficiencias en la recuperacion de contrasefias 

• Descripcion: La existencia de debilidades en el proceso de 
recuperacion de contrasenas puede permitir la recuperacion de la 
credenciales de un usuario por parte de un atacante. 

• Suite automatizada: No. 

• Verificacion Manual: Variable en funcion del servicio. 

• Correcclon: La recuperacion de contraseiias debe llevarse a cabo 
por un canal diferente al usado para su solicitud (correo electronico 
adicional, sms, ...)• La recuperacion de contrasena debe contar con 
un proceso de verificacion en tres pasos: envio de solicitud, envio 
de confirmacion, confirnnacion de recuperacion. 

Deficiencias en la gestion de sesiones de usuario 



• Descripcion: Bajo este epigrafe se agrupan un conjunto de 
deficiencias en la gestion de sesiones de usuario que pueden 
derivar en una evasion del proceso de autenticacion o en un acceso 
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no autorizado a una aplicacion haciendo uso de las credenciales de 
otro usuario. 

Los errores mas frecuentes en la gestion de sesiones de usuario son 
los siguientes: 

o Cookies con cadenas de autenticacion o predecibles: Este 
error se da en el protocolo HTTP cuando la cookie 
almacena las cadenas de autenticacion de la aplicacion 
(usuario/contrasefia) o cuando los identificadores 
generados son predecibles. 

o Cookies con atributos inseguros: Las cookies no tienen 
definidos o los tienen de forma incorrecta los atributos 
secure, HttpOnly, domain, path y expires. 

o Ataques por fijacion de sesion: No se renueva el ID de 
sesion tras el proceso de autenticacion. Esto puede 
permitir bajo circunstancias especificas, generalmente en 
sistemas de uso compartido, un usuario malintencionado 
con una sesion conocida, fuerce a otro usuario a usar el 
mismo identificador de sesion aprovechando de esta forma 
el acceso. 

o Exposicion de identificadores de sesion: Envfo de 
identificadores de sesion como parte de las peticiones sin 
cifrado o como parte de peticiones que quedan 
almacenadas en ficheros de logs (p.ej. en HTTP GET) 



• Suite automatizada: Compleja. No es frecuente que las 
herramientas automatizadas detecten correctamente estas 
deficiencias. 
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• Verificacion Manual: Se requiere del uso de un proxy de auditona 
que permita la comprobacion de las peticiones entre el cliente y el 
servldor. 

• Correccion: Los identificadores de sesion de usuario deben ser 
unicos, no predecibles, se deben renovar ante cada inicio de sesion, 
deben ser transmitidos siennpre por canales seguros y deben 
extremarse las precauciones de almacenamiento en el sistema 
local. 

Deficiencias en el cierre de sesion 

• Descrlpcion: La existencia de deficiencias en el cierre de sesion 
puede permitir a un usuario malintencionado que haga uso del 
navegador posteriormente al usuario legitinno el acceso a la sesion 
del usuario o la recuperacion de informacion cacheada. 

• Suite automatizada: No. 

• Verificacion Manual: Por un lado se debe comprobar que la sesion 
de usuario se ha cerrado de forma efectiva reintentando la 
conexion al servicio. Si se usa algun tipo de mecanismo de 
persistencia de sesion en protocolos sin estado (p.ej. HTTP) se debe 
verificar que el anterior identificador de sesion ya no es valido 
mediante el uso de un proxy de auditoria. 

Adicionalmente se debe comprobar que, en caso de usar 
mecanismos de cache locales, no se ha almacenado en ella 
informacion sensible. 

• Correccion: La sesion del usuario debe finalizar de forma correcta y 
en caso de usarse mecanismos de fijacion de sesion en protocolos 
sin estado, los identificadores de sesion no deben reutilizarse. Asi 
mismo, transcurrido un tiempo maximo, la sesion deberia finalizar 
automaticamente. Por ultimo, en la cache local, no se debe 
almacenar informacion sensible. En el caso de protocolo HTTP 
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existe una directiva "no-cache" para evitar que el navegador 
ainnacene ciertos tipos de pagina. 

Deficiencias en la implementacion de codigos CAPTCHA 

• Descripcion: La existencia de deficiencias la gestion de CAPTCHAS 
puede pernnitir a un usuario nnalintencionado la ejecucion masiva 
de acciones sobre el sistenna: registro de usuarios, connentarios, ... 

• Suite automatizada: Posible. No incluida en herramientas de 
evaluacion autonnatizada de vulnerabilidades. Existen herramientas 
especificas para verificar la robustez de las innagenes generadas. 

• Verificacion Manual: Los aspectos a verificar son varios. Por un 
lado si existe algun tipo de secuencialidad, predictibilidad o 
infornnacion adicional que pernnita la rotura de los captchas 
generados. Por otro si los captchas se apoyan en algun tipo de 
proceso que pueda ser emulado por connputador (p.ej. la ejecucion 
de operaciones matennaticas). Finalmente, se recomienda el uso de 
una herramienta autonnatizada como PWNtcha. 

• Correcclon: La recomendacion general es el uso de CAPTCHAS de 
probada eficacia como reCAPTCHA u otros. 

^ EJEMPLO 2-10 - CAPTCHAS vulnerables 

El ejempio esta basado en un caso real. En este caso las imagenes 
CAPTCHA habian sido pregeneradas y el nombre de fichero usado 
era el mismo que el texto utilizado como CAPTCHA. 




<IMG SRC="87682J2HJ2HJ212JJ1HMN.PNG" /> 
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2.4 I Vulnerabilidades en la autorizacion 
Cross-Site Request Forgery 

• Descripcion: El Cross-Site Request Forgery (CSRF) es un tipo de 
ataque hibrido de autorizacion y autenticacion. Su fundamento es 
la posibilidad que tiene un usuario malintencionado de redirigir a 
un usuario legltinno a una aplicacion en la que se encuentra 
autenticado realizando una accion que de otra manera no podria 
ejecutar. 

• Suite automatizada: Actualnnente no existen herramientas 
autonnatizadas para la verificacion de este tipo de vulnerabilidades. 

• Verificacion Manual: Se realiza nnediante el uso de un proxy de 
auditoria que permita analizar el funcionamiento del servicio e 
intentar identificar peticiones susceptibles de ser aprovechadas de 
fornna nnaliciosa. En HTTP seran candidatas prioritarias todas 
aquellas peticiones GET que realicen acciones sobre los aplicativos. 
Las peticiones POST tambien pueden ser aprovechadas para esta 
finalidad. 

• Correccion: La reconnendacion generica es la inclusion de un 
parametro variable en cada peticion de usuario, de tal fornna que 
solo un usuario que legltimannente se encuentre navegando pueda 
conocersu existencia. 





Respuesta previa 




<a hrftf="loain.DhD?id=5375c17ad1b3b'>ENLACE</ai> j 



http://host/login.php?id= 



FIGURA 2-12 
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Deficiencias de path transversal 

• Descripcion: El path transversal es un tipo de ataque que consiste 
en la manipulacion de los parametros provenientes de usuario, 
concretamente de los utillzados para el acceso a ubicaclones de 
fichero, tanto locales como remotas, de tal forma que las acciones 
que originalmente se realizan sobre un fichero puedan ser 
reallzados sobre otros. 

El path transversal presenta un impacto particularmente critico 
cuando el atacante puede controlar toda la ruta usada, bien porque 
se reciba en un unico parametro, bien porque existan 
vulnerabilidades de tipo null-byte injection que permitan modificar 
la cadena. 

• Suite automatizada: Si, de tipo indirecto. Dado que el path 
transversal no deja de ser una deficiencia de validacion en la 
entrada del usuario, la herramientas automatizadas que 
masivamente realizan pruebas sobre parametros de usuario es 
probable que detecten errores de tipo path transversal al modificar 
los parametros provenientes del usuario. 

• Verificacion manual: La verificacion manual requiere del use de 
proxy de auditorfa o de comunicacion directa con el servicio que 
permita modificar las peticiones habituales realizadas para incluir 
cadenas que incluyan rutas. Ejemplos tipicos son [../../../../], 
[http://host/file], [file.ext] , [%2e%2e%2f] o [..%cO%af] 

• Correccion: Se debe proceder a la sanitizacion de parametros 
procedentes de usuario que vayan a ser utilizados en acceso a 
ficheros seran locales o remotos. Una recomendacion generica es 
utilizar como parametros valores alfanumericos [aZ,0-9] y desechar 
cualquier otro tipo de peticion. 
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^ EJEMPLO 2-11 - PATH transversal 

El ejemplo esta basado en una vulnerabilidad real descubierta en 
un proceso de revision sobre el servicio de correo web Postman. 

La vulnerabilidad necesita de un usuario del webmail. 

Su explotacion se realiza mediante la construccion de un correo 
electronico malformado en el que los adjuntos tienen por nonnbre 
de fichero rutas reales del sistema. Este correo tiene por 
destinatario el usuario del webmail controlado por el atacante 

Una vez que el correo ha sido enviado, al leerlo desde el servicio de 
de correo web Postman, una vulnerabilidad de path transversal 
permite el acceso a los ficheros localmente existentes en la 
maquina a los que el servicio tenga acceso. 

En el ejemplo se muestra la lectura de los fichero: httpd.conf, 
/etc/passwd, /etc/vsftab y /etc/motd. 



From: "SG6" <sg6@sg6.es> 
To: [Undisclosed] 

Subject: Lectura Remota de Ficheros en Postman 2.x 
Date: Wed, 27 Feb 2008 17:18:21 +0100 
MIME-Version: 1.0 
Content-Type: multipart/mixed j 

boundary=" =_NextPart_000_0012_01C87964.C5B0FBE0" 

[..] 

=_NextPart_000_0012_01C87964.C5B0FBE0 

Content-Type: text/plain; 

name=" ../../../../../../../. . /usr/local/apache2/conf /httpd . conf " 
Content-Transfer-Encoding: 7bit 
Content-Disposition: attachment; 

filename=". ./. ./. ./. ./. ./../. ./. ./usr/local/apache2/conf /httpd. con 

f" 

httpd.conf 
[..] 
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Lectura Remota de Ficheros en Postman 2.x 



los 




RespQnder | Responder a todos | Reenvraf | Imprirtiir | Suprimir | Mostrar original 



Lectura Remota de Ficheros en Postman 2.x 



4 .iicliivos .nljiiiitos — Descaraar todos los archivos adjuntos 



□ 




3BK Descargar 



□ 



. ./. ./../. ./. ./../. ./. ./ etc/p asswd 

1 K Descaraar 



□ 



../../../../../../../../etcMstab 

1 K Descargar 



□ 



/../etc/motd 



1 K Descargar 
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Evasion del esquema de autorizacion v escalada de privilegios 

• Descripcion: La evasion del esquema de autorizacion se da cuando 
mediante el uso directo de una peticion conocida o predecible (p.ej. 
una URL) se puede acceder a zonas del sistema de informacion para 
las que el usuario no tiene privilegios de acceso o no debiera poder 
acceder (p.ej. por encontrarse aparentemente deshabilitadas). 

Cuando la zona a la que se le permite el acceso ademas cuenta con 
privilegios superiores a los que el usuario posee en origen, nos 
encontramos ante una escalada de privilegios. 

Paralelamente cuando la autorizacion nos permite alterar el flujo 
logico de funcionamiento del aplicativo o las restricciones 
funcionales, nos encontramos con un ataque a la logica de negocio. 

• Suite automatizada: No es un procedimiento automatizable de 
forma sencilla y no suele ser detectados por herramientas 
automatizadas puesto que no son capaces de discernir que es lo 
que nos debe ser autorizado de forma legftima y que es lo que no. 



• Verificacion manual: La verificacion manual requiere del uso de 
proxy de auditorfa o de comunicacion directa con el servicio que 
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permita modificar las peticiones a partir de patrones conocidos, de 
identificadores incrementales, ... 

• Correccion: Ante cada peticion es obligatorio que el sistema 
veriflque los siguientes aspectos: 

o Si el usuario cuenta con los privilegios necesarios para 

desarrollar la accion. 
o Si la accion se encuentra activa en el sistenna. 
o Si la accion a desarrollar requiere de precondiciones y si 

estas han sido satisfechas. 

Condiciones de carrera 

• Descripcion: La condicion de carrera es una caracterfstica propia de 
los sistemas concurrentes que bajo determinadas circunstancias 
puede ser aprovechada por un atacante para obtener privilegios en 
el sistema de informacion. 

Condiciones de carrera pueden existir tantas y tan variadas como 
situaciones concurrentes se planteen en el sistenna de informacion. 

Un ejempio, tipico, de condicion de carrera puede que puede ser 
aprovechado por un usuario malicioso para ganar privilegios en el 
sistema es la creacion de ficheros temporales con nombres 
predecibles sobre rutas compartidas localmente (ej. /tmp) o, mas 
peligroso, sobre el arbol web. 

Otras situaciones pueden ser mas complejas de detectar y se 
pueden dar cuando dos usuarios intentan acceder a la misma 
funcion al mismo tiempo para realizar acciones que debieran estar 
coordinadas entre ellas. 

El ejempio mas comun es el de transacciones simultaneas en 
ausencia de mecanismos de control de la concurrencia. 
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Proceso 1 




A=A+1 












Proceso 1 




A=A+2 


A 



El grafico de la figura adjunta ejempllfica el 
problema con una variable global llamada A y 
dos procesos que realizan diferentes acciones 
sobre ella. 

Al no existir control de concurrencia se pueden 
dar las siguientes circunstancias: con un 50% de 
probabilidad A valdra 13, con un 25% de 
probabilidad A valdra 11 y con un 25% de 
probabilidad A valdra 12. 



Suite automatizada: No existen herramientas que permitan la 
autonnatizacion de esta prueba. 



• Verificacion manual: La verificacion manual requiere del use de 
proxy de auditorfa o de comunicacion directa con el servicio que 
permita modificar las peticiones a partir de patrones conocidos, asi 
como la posibilidad de simular concurrencia. En algunas ocasiones 
el uso de herramientas para pruebas de carga (P.ej. JMeter) puede 
ser util para el descubrimiento de este tipo de errores. 

• Correccion: En un sistema concurrente donde los usuarios pueden 
competir por un recurso es necesario: 



o Minimizar el numero de recursos por los que compiten, 
impidiendo en la medida de lo posible la circunstancia. En 
el caso de funciones de escritura en disco, se usaran 
preferiblemente ficheros independientes por usuario, con 
nombre unico y aleatorio. 



O En los casos que sea imprescindible el uso de accesos 
concurrentes a un recurso se debe garantizar la exclusion 
mutua y la atomicidad de las operaciones que impliquen 
escritura de informacion. 
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2.5 I Vulnerabilidades EN lavalidacion 

Las vulnerabilidades en la validacion son el tipo de error mas 
comun y frecuente en los servicios web y no-web. 

Este tipo de errores tienen aunque tienen un impacto variable en 
funcion de la funcion en la que se contenga el fallo suelen ser de los errores 
mas graves que existen en un servicio. 

Afortunadamente son los errores mas sencillos de detectar y los 
que mejor responden al tratamiento automatizado, junto con los de 
configuracion. 

Cross-Site Scripting (XSS) 

• Descripcion: El Cross-Site Scripting es un tipo de ataque sobre el 
cliente que hace uso de la aplicacion. Aunque su uso mas frecuente 
es en aplicativos web, puede presentarse en cualquier aplicacion 
cliente servidor que haga uso de componentes de representacion 
HTML/JS para representar de informacion: aplicaciones moviles, 
clientes locales con navegadores incrustados, ... 

En esencia el XSS consiste en que el cliente de la victima interprete 
codigo HTML o codigo JS de tal forma que el usuario pueda obtener 
acceso a informacion de la sesion de navegacion, lanzar ataques 
CSRF mas sofisticados y finalmente poder suplantar la sesion de 
usuario. 

Existen dos tipos de ataque XSS: ataques reflejados y ataques 
almacenados. 

Los ataques reflejados se fundamentan en el envfo al servidor de 
una URL que contienen etiquetas HTML/JS y que el servidor 
muestra en la salida de la peticion. 

En la [figura 2-15] se muestra el ejempio mas comun donde un 
parametro de usuario con codigo HTML se muestra sin filtrar. 
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Search: <b><i>hola! 



Searched for hola! 
Found nothing. 



Search 



FiGURA 2-15 

Los ataques almacenados se dan cuando el usuario malicioso puede 
almacenar datos en el aplicativo, bien sean como parte de su perfil 
de usuario, bien sea como parte de sus mensajes en foros o en 
sistennas de connentarios. 

En estos casos el codigo HTML se ainnacena en el servidor y se 
muestra a todo usuario que visite el elemento afectado. Por 
ejennpio, si es el perfil de usuario esto hara que todo usuario que 
visite el perfil del usuario nnalicioso pueda ser potencialnnente 
afectado por el vector de ataque XSS. 

• Suite automatizada: SI. Exito elevado. La prueba se encuentra 
incluida de fornna connun en nnultitud de herrannientas 
autonnatizadas de analisis web: w3af, skipfish, vega, etc. 

• Verificacion Manual: Su ejecucion manual requiere, en el caso 
web, del uso de un proxy de auditoria o de la comprobacion del 
codigo HTML devuelto por cada peticion. 



• Correccion: Se recomienda limitar el uso de entradas con formatos 
enriquecidos, filtrando automaticamente cualquier etiqueta HTML 
y prefiriendo siempre el uso de representaciones alfanumericas 
basicas. 
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SQL Injection (SQLi) 

• Descripcion: Las vulnerabilidad de Inyeccion SQL permiten alterar el 
contenido de una consulta SQL ejecutada por el servicio mediante 
la manipulacion de los parametros provenientes de usuario que son 
usados como parte de la sentencia SQL. 

El exito en una inyeccion SQL permite a un atacante leer datos 
sensibles de la base de datos, modificar los datos 
(insertar/actualizar/borrar), evadir procesos de autenticacion, 
realizar operaciones de administracion sobre la base de datos 
(como reiniciar el SGDB), recuperar el contenido de un archivo del 
sistema de archives del SGBD y, en algunos casos, ejecutar ordenes 
en el sistema operative. 

Existen diferentes tipologias de ataque SQL en funcion de si se 
devuelve informacion directamente al atacante o si este, mediante 
el uso de peticiones que desencadenan una respuesta logica 
bievaluada, es capaz de inferir peticion a peticion la informacion 
almacenada en la base de datos. 

• Suite automatizada: Sf. Descubrimiento por malformacion de 
peticiones. La prueba se encuentra incluida de forma comun en 
multitud de herramientas automatizadas de analisis web: w3af, 
skipfish, vega, etc. 

• Verificacion IVIanual: Su ejecucion manual requiere, en el caso 
web, del uso de un proxy de auditorfa o comunicacion directa con 
el servicio que nos permita verificar la informacion devuelta. 

La tecnica mas comun para verificacion manual es la introduccion 
de una comilla simple [ ' ] en los parametros provenientes de 
usuario que en caso de alterar la consulta es probable que 
provoquen un malfuncionamiento de la aplicacion. Otras tecnicas 
comunes son la inclusion en los parametros de las cadenas 'AND 
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1=1 y ' AND 1=2. La primera no debe alterar el funcionamiento, 
mientras que la segunda si. 

• Correccion: Se debe validar y sanitizar toda entrada proveniente de 
usuario, escapando adecuadamente los caracteres especiales SQL 
que se puedan encontrar contenidos en ella. 

Asf nnisnno, siennpre que sea posible se reconnienda el uso de 
parannetros nunnericos y el rechazo de la peticion en caso de que el 
tipo de dato recibido no sea numerico. 

^ EJEMPLO 2-12 - Evasion de la autenticacion por SQLi 

El ejennpio nnuestra una de las funcionalidades nnas basicas de la 
inyeccion de SQL: la evasion de un proceso de autenticacion. 

El uso de la cadena ' OR 'l'='l tanto conno nombre de usuario, como 
contraseina, hace que procesos de autenticacion programados de 
fornna poco robusta puedan ser evadidos. 

La consulta que provoca la evasion suele ser sinnilar a: SELECT * 
FROM usuarios WHERE username='l' OR '!'='!' AND password='l' 
OR T=T. 



Please enter your name and password 
name: ' Q R'1'='1 
password: ••••••••••• 

Enviar consulta 



You must log in to proceed 
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LDAP Injection (LDAPi) 

• Descripcion: Las vulnerabilidad de Inyeccion LDAP permiten alterar 
el contenido de una consulta LDAP ejecutada por el servicio 
mediante la manipulacion de los parametros provenientes de 
usuario que son usados como parte de la sentencia LDAP. 

El exito en una inyeccion LDAP permite a un atacante leer datos no 
autorizados del LDAP, evadir restricciones de acceso y en los casos 
mas severos nnodificar informacion de la estructura LDAP. 

• Suite automatizada: Si. Descubrimiento por malformacion de 
peticiones. La prueba se encuentra incluida de forma comun en 
multitud de herramientas automatizadas de analisis web: w3af, 
skipfish, vega, etc. 

• Verificacion Manual: Su ejecucion manual requiere, en el caso 
web, del uso de un proxy de auditoria o comunicacion directa con 
el servicio que nos permita verificar la informacion devuelta. 

La comprobacion se realiza mediante la insercion de caracteres 
especiales LDAP como son ( I & *. 

La idea de explotacion es bastante similar a la explotacion de SQLi. 
En este caso lo que se intenta es que los filtros LDAP construidos 
para consulta beneficien al usuario que los crea. 

Por ejempio si tenemos un filtro como el siguiente (cn="+user+") un 
usuario malintencionado puede incluir un * si la variable user es 
recibida desde el usuario y modificar el comportamiento de la 
aplicacion mostrando informacion sobre todos los usuarios. 

• Correccion: Se debe validar y sanitizar toda entrada proveniente de 
usuario, escapando adecuadamente los caracteres especiales LDAP 
que se puedan encontrar contenidos en ella. 
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XML/XPath Injection 

• Descripcion: Las vulnerabilidad de Inyeccion XML/XPath permiten 
modificar la consulta y parseo de la informacion contenida en 
ficheros XML. 

La principal utilidad de las inyecciones de XML/XPath es la evasion 
de controles de autenticacion, la lectura de ficheros y la elevacion 
de privilegios. 

• Suite automatizada: Si. Descubrimiento por malformacion de 
peticiones. La prueba se encuentra incluida de forma comun en 
multitud de herramientas automatizadas de analisis web: w3af, 
skipfish, vega, etc. 

• Verificacion IVIanual: Su ejecucion manual requiere, en el caso 
web, del uso de un proxy de auditoria o comunicacion directa con 
el servicio que nos permita verificar la informacion devuelta. 

La comprobacion se realiza mediante la insercion de caracteres 
especiales XPath como son ' " >< <!- & 

• Correcclon: Se debe validar y sanitizar toda entrada proveniente de 
usuario, escapando adecuadamente los caracteres especiales XML 
que se puedan encontrar contenidos en ella. 

Inyeccion de codigo ejecutable 

• Descripcion: Las vulnerabilidad de inyeccion de codigo ejecutable 
afectan, principalmente, a servidores web y de aplicacion con 
capacidad de ejecucion de contenido dinamico (php, asp, jsp, jar, 
...). 

Este tipo de vulnerabilidades se dividen en 3 grandes grupos: 
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o Inyeccion de comandos de sistema: se produce cuando una 
llamada al sistema operative se crea a partir de 
informacion proveniente del usuario. Ejemplos tfpicos son 
la concatenacion de connandos o el uso de redirecciones. 

o Escritura de dates en disco: se produce cuando la 
informacion de usuario es escrita en ficheros que por el 
motive que sea pueden ser interpretados come codigo 
ejecutable por el servidor (per la extension, perque sean 
incluides per el software, ...). 

o Subida de ficheros: se produce cuando el usuario es capaz 
de tener control sobre la extension de fichero que puede 
crear y acceso al mismo, o cuando el fichero creado es 
interpretado por el servidor por cualquier motive. 

Suite automatizada: Sf. Descubrimiento por malformacion de 
peticiones. La prueba se encuentra incluida de forma comun en 
multitud de herramientas automatizadas de analisis web: w3af, 
skipfish, vega, etc. 

Verificacion Manual: Su ejecucion manual requiere, en el caso 
web, del uso de un proxy de auditoria o comunicacion directa con 
el servicio que nos permita verificar la informacion devuelta. 

Correccion: Se debe validar y sanitizar toda entrada proveniente de 
usuario, escapando adecuadamente los caracteres especiales, 
controlando la existencia de etiquetas del lenguaje, asi como las 
salida de informacion a disco. 

EJEMPLO 2-13 - Inyeccion de comandos 

El ejempio muestra una inyeccion de comandos tipica en PHP. 
Concretamente una inyeccion en 2 fases. 
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En la primera fase el atacante es capaz de escribir en un fichero del 
servidor codigo PHP valido. En el ejennpio suponennos <? phpinfo(); 
?>. 



En la segunda fase el atacante es capaz de ejecutar ese fichero por 
un error de validacion y control de la inclusion, lo que hace que PHP 
lea el fichero e interprete su contenido, ejecutando el codigo PHP 
que encuentre en el. 



© 



©< 



/write?info=<? phpinfo(); ?> 



/include?file=info.txt 



info.txt 



info.txt 



FIGURA 2-17 



Desbordamientos de buffer y cadenas de formato 



• Descripcion: Este tipo de vulnerabilidades son dependientes de la 
plataforma y del lenguaje utilizado para el desarrollo. En principio, 
software desarrollado con lenguajes que no pernniten la 
innplennentacion de acceso directo a nnennoria estan exentos de 
ellos, siempre que no hagan uso de invocaciones a nnodulos 
externos desarrollados en lenguajes inseguros (ASM, C, C++, ...). 



El objetivo del atacante en este tipo de vulnerabilidades consiste en 
llegar a nnodificar el flujo de ejecucion del progranna tonnando el 
control sobre las direcciones de retorno, bien sobre las 
almacenadas directamente en pila, bien indirectannente en 
funciones de liberacion de nnennoria dinamica. 
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Suite automatizada: Si. Descubrimiento por malformacion de 
peticiones. La prueba se encuentra incluida en algunas 
herramientas automatizadas de analisis web de forma completa o 
parcial: w3af, skipfish, vega, etc. 

Verificacion Manual: Su ejecucion manual requiere, en el caso 
web, del uso de un proxy de auditoria o comunicacion directa con 
el servicio que nos permita verificar la informacion devuelta. 

La mecanica de testeo consistira, en el caso de los desbordamientos 
de buffer, en hacer crecer el tamano de los parametro enviados al 
servidor hasta alcanzar errores por peticiones excesivamente 
largas. Si antes de alcanzar esos errores se llega a un 
malfuncionamiento del servicio (p.ej. Errores de tipo 500 en 
aplicativos CGI o caida del servicio en otros) podemos estar ante un 
desbordamiento de buffer. En el caso de cadenas de formato, se 
enviaran como parametro las peticiones %n y %x que alteraran el 
funcionamiento de la aplicacion volcando fragmentos de pila si la 
aplicacion se encuentra afectada por un error de cadenas de 
formato, tambien es posible que se produzca una caida del 
aplicativo al recibir este tipo de parametros. 

Correccion: Cuando se trabaja con lenguajes que permiten el 
acceso directo a memoria es necesario controlar en todo momento 
el tamano de los buffers y el desbordamiento de los enteros. En el 
caso de C/C++ se recomienda encarecidamente el uso de funciones 
seguras strncpy y derivadas en detrimento de la familia strcpy y 
derivadas. El correcto formato de las funciones de impresion de 
cadenas es necesario cuando se trabaja con C/C++. Por ello toda 
funcion de la familia print debe contar con la cadena de formato 
que va a recibir. 



Vulnerabilidades | 2 



2.6 I Tabla resumen 



Subtipo 



Deteccion Auto. 



Suites 



Herramienta Man. 



Config. 


SSL 


Si 


OpenVAS, Nexpose, ... 


testssl.sh 


Config. 


DB Listener 


Si 


OpenVAS, Nexpose, ... 


LSNRCTL/nmap 


Config. 


Debug 


Si 


OpenVAS, Vega, ... 


nc / telnet 






Parcial 


OpenVAS, Nexpose, ..1 




Config. 


Herram. Admon. 


Si. IVIejorable 


OpenVAS, Vega, ... 


nikto / wikto / ... 


Config. 




Si. Mejorable 


OpenVAS, Vega, ,.. 


nikto/ wikto / ... 


Config. 


Comentarios WEB 


Si. 


w3af, vega, sl<ipfish ... 


zed / burp / ... 


Config. 


Bacl<up WEB 


Si. IVIejorable 


w3af, vega, sl<ipfish ... 


nikto/ wikto / ... 


Config. 


Ext. NO-WEB 


Parcial 


sl<ipfish, wapiti, ... 


nikto/ wikto / ... 


Confi. 


Indexacion 


Si. IVIejorable 


w3af, vega, sl<ipfish ... 


nikto/ wikto / ... 


Config. 


IVietodos HTTP 


Si. No comun. 


w3af 


nc/ telnet 



Logica 



Autent. 



Canal Cifrado 



Si. 



OpenVAS, Vega, 



Variable 



wireshark 



mmm 




Autoriz. 


Path Transversal 


Si. Malformacion. 


w3af, vega, skipfish ... 


zed / burp / nc 


^utoriz. 


Evasion 




^1 No 


B NO 1 


zed / burp / nc 


Autoriz. 


^Race Condition 




No 


■ N° 1 


jmeter fl 


Valida. 


XSS 


Si. 


wBaf, vega, skipfish ... 


zed / burp / nc 


Valida. 


SOU 


Si. 


wBaf, vega, skipfish ... 


zed / burp / sqimap 


Valida. 


LDAPi 


Si. 


w3af, vega, skipfish ... 


zed / burp / nc 


Valida. 


XML/Xpatii Inj. 


Si. 


w3af, vega, skipfish ... 


zed / burp / nc 


Valida. 


Inyeccion Codigo 


Si. Malformacion. 


w3af, vega, skipfish ... 


zed / burp /nc 


Valida. 


Desbordamientos 


Si. Malformacion. 


w3af, vega, skipfish ... 


zed / burp /nc 



FIGURA 2-18 
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Herramientas I 3 



Un nuevo capitulo. Si en el numero dos hemos visto las 
vulnerabilidades nnas frecuentes, en este nunnero tres toca pasar a analizar 
las herrannientas de las que disponemos para descubrir y explotar las 
vulnerabilidades expuestas en el capitulo dos. 

Este es un capitulo de introduccion a las herramientas, con un nivel 
de profundidad basico y un enfoque practico. 

No es este un manual de todas las herramientas disponibles, ni 
tampoco una gula detallada del uso de cada una. 

Puedes considerar este capitulo como una guia introductoria a las 
funcionalidades mas comunes y al uso basico de cada herramienta. Dejando 
a discrecion de cada lector el profundizar en cada una de ellas 

• Herramientas para seguridad en redes y servidores. NMap, Netcat, 
OpenVAS, Nexpose, Nikto/Wikto o Hydra son algunas de las 
herramientas fundamentales para la ejecucion de las pruebas 
necesarias para la deteccion de las vulnerabilidades comentadas en 
el segundo capitulo pertenecientes a servicios de red y servidores. 

• Herramientas para seguridad en aplicativos web. Vega, Skipfish, 
Arachni o ZED Attack Proxy (ZAP) son algunas de las herramientas 
fundamentales para la ejecucion de las pruebas necesarias para la 
deteccion de vulnerabilidades comentadas en el segundo capitulo y 
pertenecientes a servicios y aplicativos web. 




74 
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3.1 I Seguridad en redes y servidores: nmap y netcat 

NMap y Netcat son las dos herramientas basicas con las que se 
pueden realizar verificaciones de deficiencias en servicios de red. Mediante 
NMap seremos capaces de detectar la existencia de servicios y de sus 
versiones y mediante Netcat seremos capaces de comunicarnos con ellos 
recibiendo en todo momento el flujo de comunicacion en formato crudo. 

Usando NMap 

NMap es una herramienta de escaneos de puertos que nos 
permitira de forma rapida determinar la visibilidad de servicios de red del 
sistema de informacion a evaluar. 

Existen entornos /rontenof para su gestion, pero se recomienda su 
uso directo en Imea de comandos. La sintaxis basica de uso es la siguiente. 

$ nmap 192.168.1.1 

Starting Nmap 6.00 ( http://nmap.org ) at 2014-05-12 21:50 CEST 

Nmap scan report for 192.168.1.1 

Host is up (0.11s latency). 

Not shown: 996 filtered ports 

PORT STATE SERVICE 

23/tcp closed telnet 

80/tcp open http 

1900/tcp closed upnp 

8080/tcp closed http-proxy 

Nmap done: 1 IP address (1 host up) scanned in 40.61 seconds 

FiGURA 3-1 

A partir de esta sintaxis basica se pueden incluir modificadores para 
ampliar la informacion mostrada. La figura [3-2] muestra el resultado de 
incluir el modificador -A que realizar una deteccion de versiones, tanto de 
los servicios instalados como del propio sistema. 

$ nmap -n -A 192.168.1.1 

Starting Nmap 6.40 ( http://nmap.org ) at 2014-05-12 21:51 CEST 

Nmap scan report for 192.168.1.1 
Host is up (0.018s latency). 
Not shown: 996 filtered ports 
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PORT STATE SERVICE VERSION 

23/tcp closed telnet 
80/tcp open tcpwrapped 
1900/tcp closed upnp 
8080/tcp closed http-proxy 

MAC Address: 28:BE:9B:B7:49:46 (Technicolor USA) 
Device type: broadband router 

Running: Cisco embedded. Motorola embedded. Scientific Atlanta embedded 
OS details: Cisco EPC3925 or Motorola SURFboard SB5101 
Network Distance: 1 hop 

TRACE ROUTE 

1 18.29 ms 192.168.1.1 

Nmap done; 1 IP address (1 host up) scanned in 109.59 seconds 



FiGURA 3-2 

Otros modificadores interesantes pueden ser el parametro "-p" que 
permite especificar un rango de puertos, el parametro "-P0" que evitar que 
se intente establecer una conexion inicial ICMP al host, el parametro "-n" 
que evita la resolucion de nombres, el parametro "-sS" para establecer un 
modo de escaneo en base a petlclones SYN sin necesidad de establecer una 
negociacion TCP completa y el parametro "-sU" para escaneo de sockets 
UDP. 



$ sudo nmap -n -A -sS -P0 -p 1-65535 192.168.1.1 

Starting Nmap 6.40 ( http://nmap.org ) at 2014-05-12 22:03 CEST 

Nmap scan report for 192.168.1.1 
Host is up (0.0022s latency). 
Not shown: 65531 filtered ports 
PORT STATE SERVICE VERSION 

23/tcp closed telnet 
80/tcp open tcpwrapped 
|_http-title: HTTP 401 - Unauthorized 
1900/tcp closed upnp 
8080/tcp closed http-proxy 

MAC Address: 28:BE:9B:B7:49:46 (Technicolor USA) 
Device type: broadband router 

Running: Cisco embedded. Motorola embedded. Scientific Atlanta embedded 
OS details: Cisco EPC3925 or Motorola SURFboard SB5101E 
Network Distance: 1 hop 
TRACE ROUTE 

1 2.23 ms 192.168.1.1 

Nmap done: 1 IP address (1 host up) scanned in 195.59 seconds 



FiGURA 3-3 
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Usando Netcat 

Netcat y el mas moderno Socat son herramientas de comunicacion 
directa a sockets TCP/UDP tanto en IPv4 como en IPv6 y mediante socat es 
posible establecer comunicaciones a traves de SSL. 

La [figura 3-4] muestra diversos ejemplos de conexion: a un servicio 
http, a un servicio smtp y haciendo uso de socat a un servicio HTTPS. 



$ nc www.google.es 80 
HEAD / HTTP/ 1.0 

HTTP/1.0 302 Found 

Cache-Control: private 

Content-Type: text/htmlj charset=UTF-8 

Location : http : //www . google . es/ ?gf e_rd=cr&ei=q0WPU- -DIIzA8getw4CQAQ 

Content- Length : 258 

Date: Mon, 12 May 2014 21:25:45 GMT 

Server: GFE/2.0 

Alternate-Protocol: 80:quic 

$ nc aspmx.l. google. com 25 

220 mx.google.com ESMTP wf 5si5727852wjb.92 - gsmtp 
HELO localhost 

250 mx.google.com at your service 

MAIL FROM: <root@localhost . local> 

250 2.1.0 OK wf5si5727852wjb.92 - gsmtp 

RCPT TO: <labs@sg6.es> 

250 2.1.5 OK wf5si5727852wjb.92 - gsmtp 

$ socat - SSL: www. google. es:443jverify=0 
HEAD / HTTP/ 1.0 

HTTP/1.0 302 Found 

Cache-Control: private 

Content-Type: text/htmlj charset=UTF-8 

Location : https : //www. google. es/?gfe_rd=cr&ei=Q0iPU_nnDI7A8ge ^4HAAQ 

Content- Length : 259 
Date: Mon, 12 May 2014 21:24:35 GMT 
Server: GFE/2.0 
Alternate-Protocol: 443:quic 



Figura 3-4 
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3.2 I Seguridad en redes y sistemas: openvas, nexpose, ... 

Si NMap y Netcat son las dos herramientas basicas con las que 
manualmente podremos verificar gran parte de las vulnerabilidades, 
OpenVAS y Nexpose CS son justo el extremo contrario: dos grandes suites 
automatizadas de deteccion de vulnerabilidades. 

La principal ventaja de estas herramientas es lo sistematico de la 
revision. Nosotros no somos maquinas y muchas veces nos cuesta probar 
durante horas todas las posibles combinaciones de errores de un sistema de 
informacion. 

For contra, el problema de este tipo de suites altamente 
automatizadas es la cantidad de falsos positivos que generan, sobre todo si 
no se establecen Ifmites a las pruebas a realizar. Debilidad que comparten 
tanto OpenVAS, como Nexpose, como Nessus, como Retina; por citar las 
mas conocidas tanto libres como propietarias. 

Algunas de las comparativas publicas existentes ^ de estas 
herramientas evidencian como para un sistema de pruebas con 15 
vulnerabilidades son capaces de generar hasta un centenar de alertas 
diferentes para, finalmente, de las 15 vulnerabilidades detectar 
correctamente, en el mejor de los casos, 7. 

Por tanto, al hablar de suites automatizadas, tambien conocidas 
como herramientas de baton gordo hay que tener en cuenta dos factores: 
su falta de precision y la cantidad de informacion irrelevante que generan. 
Por ello es muy recomendable ajustar los plugins y los perfiles de revision de 
cada una de ellas hasta niveles de informacion tolerables. 



^ http://hackertarget.com/nessus-openvas-nexpose-vs-metasploitable/ 
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Usando OpenVAS 

OpenVAS es una herramienta cliente-servidor sucesora de Nessus 
en el nnundo del OpenSource, tras el paso de Nessus a solucion comercial. 

Su funcionamiento es relativannente sencillo: por un lado existe un 
servicio funclonando en background y por otro un interfaz cliente que para 
ejecutar evaluaciones de vulnerabilidades. 

Las principal particularidad es la necesidad de crear un usuario en el 
servicio, nnediante el uso del connando openvas-adduser. Una vez hemos 
anadido un usuario podrennos conectar desde nuestro cliente como se 
nnuestra en la [figura 3-5]. 



ConectadD al servlclor OpenVAS 

Servidor OpenVAS 

Sisterra: 



+ X 



Puerto: 



localhost 



9390 



I Omision I 



AutentfcBcion 
Us J Brio: 



user 



Contrasena: 



Autentfcacfon por certificado 



CA de confianza: 



cacert.pem 



Selecclonando. 



Utilizar fichero de certificado: 
f 



Utilizar clave en fichero: 



Seleccionando. 



Cancel 



OK 



Figura 3-5 
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Al establecer conexion podremos ajustar los parametros basicos de 
configuracion de las pruebas. Es importante limitar entre otros el tipo de 
pruebas que se pueden realizar (opcion pruebas seguras) asi como los 
niveles de concurrencia. Otro aspecto a considerar son los complementos 
(plugins) que van a ser ejecutados durante la prueba. 



Opcion es 

2 Complementos 
E] Credenciales 
P Seleccion de objetiv 
P Reglas de acce&o 
PrefenenciBS 
0 KB 



Opciones generales de sondeos 



Rango de puertos: 



default 



Q ConsWerar los puertos no sondeados como cerrados 
Sistemas a probar concurrentemente: 



20 



/cgi-bin:/5cript5 



Pruebas a realizar concurrentemente: 

Ruta a 105 CGIs: 

(□] Realizar una resolucion inversa de la IP antes de probarla 

(□j Optimizar la prueba 

(□) Pruebas seguras 

Q Designar sistemas por su direccion MAC 
An^lisls de puertos: 



pnscan {NASL wrapper) 


□ 


Ping Host 


n 


SYN Scan 


n 


Exclude toplevel domain wildcard host 


n 


OpenVAS TCP scanner 


Q 


Nmap (IMASL wrapper) 


n 


ike-scan (NASL wrapper) 


n 
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Una vez dispongamos de la configuracion general de la prueba, 
podennos proceder a usar el asistente de sondeos para crear un nuevo 
proceso de revision mediante el uso del asistente de sondeos. Este asistente 
nos permitira definir los objetivos del proceso de revision junto con 
informacion descriptiva del proceso y finalnnente lanzara la ejecucion de la 
prueba. 



Herramientas | 3 



Es posible definir mas de un sistema a evaluar, bien mediante el uso 
de direccionamiento por clases, bien mediante el uso de una lista de hosts 
separados por comas. Adicionalmente algunos sondeos pueden requerir el 
uso de credenciales adicionales de acceso {ssh, smb, ..), que deben ser 
definidas en la configuracion global de la prueba. 



Asistente de sondeos 



Paso 1: larea 



Paso 2: Amblto 



Paso 3: Ob|etlvos Paso 4: Ejecutar 



Las tareas describen lo que desea hacer. Rjede utilizarlas para agrupar 
de forma logica 5U trabajo por asunto, frecuencia, ubicacion o cualquier 
otra cosa. 

Algunos nombres posibles de taneas serfan: 

- Pruebas semanales 

- Cliente XYZ 

- SiBtemaB del proyecto ABC 

Tambien deberia introducir un comentario que describa mejor la tarea. 
Introduzca un nombre para 5U tarea: 

tarea sin nonnbne| j 

Comentario: 



0 



Back 



Cancel 



Forward 
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Finalmente se procedera a la ejecucion de la prueba como se 
muestra en la [figura 3-7] . 
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81 



Sondeando la red desde localhost - + x 



Nombre de 5.[Btenria An^llsis de puertos ComprobactoneB Parar 



^ 192.168.1.1 1 II I □ 



Parar toda la prueba 



FiGURA 3-8 

Como ultimo paso, una vez la prueba haya finalizado, OpenVAS nos 
mostrara un resumen de los hallazgos mas significativos. En el sistema 
usado en la prueba, un sistema actualizado sin ninguna vulnerabilidad 
publica conocida, el resultado ha sido el que se acompana. 



OpenVAS Report 

The OpenVAS Security Scanner was used to assess the security of 1 host 

2 security holes have been found 
0 security warning has been found 
2 security notes have been found 
0 false positive has been found 

FiGURA 3-9 

Usando Nexpose 

Nexpose Community es una herramienta, a pesar de su nombre, 
propietaria, aunque de uso libre, desarrollada por Rapid?, la compainfa que 
hay tras IVIetasploit. Ademas de la version Community existen diferentes 
versiones comerciales: express, consultant y enterprise. Cada version 
incrementa la funcionalidad de la anterior, siendo el principal factor 
limitante el numero de IPs que pueden evaluarse, asi como la capacidad de 
verificar mediante Metaesploit las vulnerabilidades encontradas. La version 
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Community esta limitada a la gestion simultanea de 32 IPs. Nexpose, al igual 
que OpenVAS tiene un funcionamiento en modo cliente-servidor, con un 
interfaz mediante un servicio HTTP a traves de navegador web. 

Para su descarga tendremos que rellenar un formulario de registro 
recibiremos un correo electronico con una clave de activacion similar a la 
[figura 3-10] 



Your Nexpose Community License Key 

^* h JiF , I Wil: Follow the steps below to get started 

Figura 3-10 

Una vez tengamos la clave y el binario descargado podremos 
proceder a una instalacion automatizada que tras finalizar nos mostrara en 
la uri http://localhost:3870/ \a consola web de Nexpose. 



nexpose 





Log on 




User name 




t 


] 


Password 


1 


(2) Log on 





Figura 3-11 



Tras superar el proceso de Login podremos proceder a la ejecucion 
de una prueba de seguridad desde la opcion New Static Site, donde 
definiremos las caracterfsticas generales del host a evaluar, los perfiles de la 
prueba, la necesidad de credenciales, etc. 
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Site Configuration 



Previous 



Next 



Save 



Cancel 



General 

Assets 

Scan Setup 

Credentials 

Web Applications 

Organization 

Access 



Included Assets 



The listed IP addresses and host names are included in this site. 



127.0.0.1| 



FIGURA 3-12 



Finalmente, como se puede ver en la [figura 3-13], podremos 
proceder a escanear los assets configurados mediante la opcion Scan de 
cada uno de ellos. 



Site Listing 




1 Hame 


Type Scan Status 


Scan 


Local host 


^ Static Not scanned 






Start Nevif Scan 




X 




Site Localhost 


Site Details 


Scan template 


Full audit without Web Spider 




Included assets 


127.0.0.1 








Excluded assets 











Scan Progress 


Scan Type 


Elapsed 


Assets Scanned 


Manual 


11 seconds 


1 Asset discover js?i progress... | 


Active: D. Pending: D. Complete: 0 





Figura 3-13 
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Transcurridos unos cuantos minutos, hay que ser pacientes, en la 
pestafia vulnerabilidades obtendremos los resultados del proceso. 



wi^' \ ' ' . ^ 




SMB signing disabled 




SMB signing not required 




IP Source Routing Enabled 




MS13-015; Vulnerability in .NET Framework Could Allow Elevation of Privilege (2300277) 




Database Open Access 




MS1 2-074: Vulnera^^ilities in .NET Framework Could .Allow Remote Code Execution [2745030) 




MS13-034: Vulneracility in Microsoft .Antimalware Client Could Allow Elevation of Privilege (2823432) 




Google Chrome Vulnerability: CVE-2013r-2566 





FIGURA 3-14 
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3.3 I SEGURIDAD EN REDES YSISTEMAS: OTRAS HERRAMIENTAS 



A medio camino entre las herramientas mas basicas y las soluciones 
totalmente automatizadas, aparecen herramientas que implementan alguna 
automatizacion muy concreta. Nos seran de utilidad para la realizacion de 
algunas tareas. 

THC Hydra 

THC Hydra es una herramienta multiprotocolo para la verificacion 
de contrasenas debiles. Actualmente permite mas de una veintena de 
protocolos de comunicacion, tanto con SSL, como sin SSL, entre ellos los 
mas conocidos: ftp, http, smtp, pop3, imap, Idap, ... 

THC Hydra permite el uso de listas de usuarios/contraseinas, asl 
como la generacion mediante fuerza bruta de contrasenas con diferentes 
niveles de complejidad y tamaino. 



xHydra 



n Quit 



Target Passwords 
Target 



Tuning 



Spec (lie 



@ Single Target 



O Target List 



Port 



Protocol 



Output Options- 



Start 



127.0.0.1 



□ Prefer IPV6 



pop 3 



□ Use SSL 



Q Show Attempts 



Q Be Verbose 



□ Debug 



hydra -I youmame -p yourpass -e ns -t 16 127.0.0.1 popB 
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Wikto 



Wikto (adaptacion para Windows con interfaz GUI de Nikto) es una 
herramienta que mas alia de innplennentar las funcionalidades de Nikto, 
pernnite la automatizacion de ciertas tareas de la fase de information 
gathering: google hacking, descubrinniento de rutas littp, ... 







IN3TALL_admin A 




A 


/access 










/active 




















/admin 


adminjogin 




asp 




/_admin 


adminjogon 




aspK 




/administrator 


administrator 








/administration 


admin la c|on 




bak 






back end 




l>akijp 




/app 






[fat 




^pps 








/appcenter 


(Hient 


cgi 
















dll 




/ajp 






/auth 


(MJstomer 




/aijthentioate 




Itta 




database 


fttm 


/backup 


d^lt 


Ittml 




details 


htt 








/bakijp 


ewample 






eKamples 




/banner 


feedback 


EP 



Discovered Diiect cries 
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Mas herramientas 

La lista se nos podria hacer interminable, no obstante vamos a citar 
algunas que puntualmente nos pueden ayudar: 

Maltego: Suite de recopilacion y correlacion de informacion. 

FOCA: Utilidad de evaluacion de metadatos. 

Wireshark: Herramienta de analisis de paquetes de red. 

John the Ripper: Herramienta para cracking de contrasenas. 

Metasploit: Herramienta para explotacion de vulnerabilidades. 
Aunque este libro no trate sobre ello, no esta de mas conocerla. 



SQLMap: Herramienta para explotacion de inyecciones de SQL. 
Igual que metasploit escapa del contenido de este texto. 



Evaluacion de Vulnerabilidades TIC 



3.4 I Seguridad web: zap, un proxy de auditoria 

Un proxy de auditona es una herramienta basica y fundamental, 
tanto para la ejecucion de revisiones manuales, conno para la confirmacion 
de vulnerabilidades detectadas a partir de herrannientas automatizadas. 

dComo funcionan? 

Dejando a un lado la nnayor o menor sofisticacion y automatismos 
que algunos incluyen (p.ej. rutinas automaticas para explotacion de 
inyecciones de SQL) el hecho es que un proxy de auditoria es una 
herrannienta que en su planteamiento basico es simple. Su funcion principal 
es colocarse en medio del trafico HTTP/HTTPS teniendo la capacidad de 
parar la comunicacion y modificaria, tanto en las peticiones que van desde 
el cliente al servidor, como en las respuestas que el servidor devuelve al 
cliente. 




GET/ HTTP/1.1 
Host: localhost 




HTTP/1.1200 

OK 

[..] 
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Usando ZAP: ZED Attack Proxy. 

ZED Attack Proxy (ZAP) es uno de los muchos servidores proxy de 
auditoria que existen, en este caso perteneciente al proyecto OWASP. Otros 
pueden ser BURP o Paros Proxy. 

Ademas de las caracteristicas basicas: escuchar y detener la 
comunicacion HTTP/HTTPS, ZAP incorpora funcionalidades avanzadas para 
la explotacion, asi como funciones de revision autonnatizada. No obstante, 
en esta seccion vamos a explicar el funcionamiento de ZAP como proxy 
basico para tareas manuales de localizacion, verificacion y explotacion de 
vulnerabilidades. 

Para su utilizacion, la primera tarea a ejecutar es conectar el 
navegador web con ZAP, haciendo uso de la pestaina configuracion de 
servidor proxy (que tiene una ubicacion variable segun el navegador y el 
sistema operativo). 

Una vez que tengannos el navegador integrado en el proxy, 
ennpezaremos a ver todas las peticiones que se realicen desde el navegador, 
asi como todas las respuestas que le proporcione el servidor. 



Sitios ., Scripts 



^ K'Sitios 

]_] IfiJ http://es.yahoo.com 
► L_l http://pagead2.googlesyncJication.com 

|_J ft) http://www.google.es 



http://wvvw.yahoo.es 



► , i-'-' https://es.yahoo.com 



1 Id 


Req. Timestamp 


Metodo 


1 URL 


1 Code 


1 


9/06/1411:40:16 


GET 


http://www.google.es/ 


302 


3 


9/06/1411:40:56 


GET 


http://iA/'ww.ya hoo.es/ 


301 


5 


9/06/1411:40:56 


GET 


http://es.yahoo.com/ 


301 


' 7 


9/06/1411:40:59 


GET 


https://es.yahoo.com/ 


200 



FIGURA 3-18 
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Para cada una de las peticiones, como nos muestra la [figura 3-19], 
podremos ver la comunicacion en ambos sentidos: cliente ~> servidor y 
servidor ~> cliente. 



Punto de intermpcion 



Consola de secuencia de comandos 



y Inicio Rapido 



^ Peticion 



Respuestaw 



Header: Vista Raw ▼) | Body: Vista Raw ▼) Q | | 



GET https://es.yahoo.con/ HTTP/1.1 
Connection; fceep-alive 

Accept : text/html, application/xhtml+Mnlj application/xiil; q=0.9 jimage/vjebpj*/*jq=0. S 
User-Agent; Mozilla/S.e (Windows HT 6.2; 1^64) AppleWebKit/537 . 36 (KHTML, like Gecko) Chrome/ 
35.0.1916.114 Safari/537.36 
Accept-Encoding: sdch 

Accept -Language : e5-ES,es;q=B.Sjde;q=8. 6,en;q=e.4,f r ; q=0 . 2, id ; q=0 . 2 , it ;q=6. 2 
Cookie: B=6f qek9l9pb06t8Lb=38i5=al; RMBX=6f qek0l9pb06tab=3&s=aiat=159 
Host: es. yahoo. com 



^ Punto de interrupcidn 


I j Consoia de secuencia de comandos 




-., inicio Rapido 


^ Peticidn 


Respuesta'^ 



Header: Vista Raw |^| | Body: Large Response 7^ : O CD 



I 

i 



HTTP71.1 2&0 OK 

Date: Mon^ 69 3un 2ei4 09:41:81 QMT 

P3P: policyref="http://info. yahoo. com/v<3c/p3p.>anl"j CP="CAO DSP COR CUR ADM DEV TAI PSA PSD 
IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIM COM MAV im" 
DEM CNT STA POL HEA PRE LOC GOV" 
X-Frame-Options: DENY 

Set-Cookie: DNR=deleted; e>cpires=Sun, 09-lun-2013 09:41:90 QMT; path=/; domain=. 
yahoo . com 

Set-Cookie: DNR=deleted; expires=Sunj 09-Jun-2013 09:41:00 QMT; path=/; domain= . es . yahoo . com 

Set-Cookie: PH=deleted; expires=Sun, 09-3un-2013 09:41:00 QMT; path=/; doinain=. yahoo. com 

Vary: Accept-Encoding 

Content-Type; text/html; charset=utf -S 

Age: 0 

Connection: keep-alive 



Figura 3-19 



Ademas de la capacidad de ver la connunicacion en formato crudo, 
la verdadera funcionalidad que hace util a los proxy de auditoria es la de 
parar la comunicacion mediante lo que se conoce como puntos de 
interrupcidn. Un punto de interrupcidn no es mas que una peticion que 
contiene una cadena que la identifica y que es detenida por el proxy tanto 
en el envio del cliente al servidor, como en la respuesta que el servidor le 
proporciona al cliente. 
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>^ Anadir punto de interi upcion (Break Poi... 



Location: 
Match: 

String: 

Inverse: 
Ignore case: 



URL 



Contiene 



adduser 



□ 



Cancelar 



Guardar 



FIGURA 3-20 

A partir de la colocacion del punto de interrupcion, todo el trafico 
que coincida con el patron seleccionado sera detenido, permitiendo de esta 
fornna la inclusion de vectores de ataque, la confirnnacion de 
vulnerabilidades conocidas, etc. 

La [figura 3-21] nnuestra un ejennpio con el trafico detenido y conno 
se podria nnodificar del parannetro p de la peticion HTTP, incluyendo codigo 
HTML, para verificar la posible existencia de XSS. 



Eapido ^ Peticion Respuesta'^ ^ Punto de intenupdon 



Consola de secuenda de comandos 



I Header Vista Tabular ▼] (Body: Vista Tabular tJ 



Nombre Parametro 



I Valor 



cop 

ei 

It 

toggle 
B 

RMBX 

sSN 

ypcdb 



mss 

UTF-8 

ylp-t-907 



l h:b>PENTHST</bH 



1 

6fqelcOI9pb06t&b=3&s=a1 
6fqekOI9p b06t«>b=3&s=a1 &t= 1 59 
cUNyiIY2wWGxaLbZiFfbX)qRk4HQSJIA8HNgEho 
9d6f952d 175 1 bc56fbe98532b60ed20e 



Nombre Parametro 



I Valor 



Figura 3-21 
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3.5 I SEGURIDAD web: APLICACIONES AUTOMATIZADAS 

Al igual que sucedia en el caso de la revision de sistemas y servicios 
de red, en el caso de los aplicativos web tambien existen aplicaciones de 
boton gordo (o de Knea de comandos pero con la misma filosofia) que 
comparten las virtudes y los defectos de sus primas hermanas. 

En el lado de las ventajas esta lo sistematico de la revision, mucho 
mas sistematica de lo que el comun de los humanos realizaria, y ademas el 
aceptable nivel de identificacion de vulnerabilidades de validacion (XSS, 
SQLi, ...). 

En el lado negativo, nuevamente, la enornne cantidad de 
informacion que proporcionan, en muchos casos proveniente de falsos 
positivos, que requerira de una verificacion manual y un descarte de las 
vulnerabilidades detectadas de forma erronea. 

El numero de herramientas libres o de uso gratuito en este grupo es 
amplio: skipfish, arachni, w3afo vega, por citar algunas. 

Ademas de las soluciones libres, o de uso gratuito, existen tres 
referentes en el mercado comercial: IBM Security Appscan, HP Weblnspecty 
Acunetix Web Vulnerability Scanner. Cuya principal caracterfstica distintiva 
es, a priori, un mejor control del numero de falsos positivos proporcionado^. 

En esta seccion vamos a ver el funcionamiento de tres 
herramientas libres: Skipfish, Arachni y Vega. 

Ademas, para mostrar las diferencias significativas existentes entre 
cada herramienta, se ejemplificara la diferencia entre los resultados 
ofrecidos por cada una de ellas en la evaluacion del aplicativo web 
WebGoat, un aplicativo web deliberadamente vulnerable desarrollado por 
OWASP. 



^Comparativa de herramientas de evaluacion automatizada web: http://sectoolmarket.com/price- 
and-feature-comparison-of-web-application-scanners-unified-list.html 
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Usando Skipfish. 

Skipfish es una herramienta automatizada de deteccion de 
vulnerabilidades web desarrollada por Google cuyo ultimo desarrollo es de 
diclembre de 2012. 

Es una aplicacion de linea de connandos desarrollada en C++ y 
testada en platafornnas *nix (Linux, OSX, ...) y Windows, mediante cygwin. 

Para verificar las vulnerabilidades de WebGoat con esta aplicacion 
la invocaremos de forma similar a como se muestra en la [figura 3-22] 

$skipfish -MEU -o skip_goat -A guest: guest -C 
":SESSIONID=8199BFEE17B6AE153705B00244AD31D3" -N -X 

"attack?action=Logout " http : //127 .0.0.1: 8080/WebGoat/attack 

Figura 3-22 

El parametro -MEU indica el nivel de logging, en este caso 
indicamos que se almacene informacion de transmision de credenciales sin 
HTTPS, de correos electronicos y uris encontradas, asf como de casos en los 
que las directivas de cacheo estan limitadas a HTTP/1.1 

El parametro -o especifica el directorio donde se almacenara el 
informe de salida. 

El parametro -A indica las credenciales de autenticacion HTTP. 

El parametro -C indica la cookie de sesion. Esta cookie debe 
obtenerse con una autenticacion valida interceptada con un proxy de 
auditoria (p.ej. ZED). 

El parametro -N indica que no se destruyan cookies aunque la 
aplicacion lo indique; evitando algunas salidas no previstas por errores. 

El parametro -X indica que se excluya la URL cuya cadena provoca el 
Logout de la aplicacion. 

Finalmente se indica la URL inicial desde la que auditar. 
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Ademas de estos parametros se podrian anadir otros, como el 
parametro -S para incluir un diccionario desde el que hacer fuerza bruta 
sobre el path del servidor para descubrir nuevas rutas ( de forma similar a 
como hace WIKTO ). La [figura 3-23] muestra esta opcion. 



$skipfish -MED -o skip_goat -S 

/usr/share/skipfish/dictionaries/minimal.wl -A guest:guest -C 

"DSESSIONID=8199BFEE17B6AE153705B00244AD31D3" -N -X 

"attack?action=Logout' ■ http : //127 .0.0.1: 8080/WebGoat/attack 



Figura 3-23 



La [figura 3-24] muestra la ejecucion de skipfish, donde veremos 
los resultados de rendimiento del escaneo, asl como los resultados 
intermedios que va obteniendo. 



skipfish version 2.18b by Icamtufggaogle.ccHii 


- 127.8.8,1 - 




Scan statistics: 




Scan time : 


0:01:53.512 


HTTP requests : 


18298 (162. 8/s), 390999 kB in, 6362 kB out (3500.6 kB/s} 


Compression : 


0 KB in, 0 kB out (0.0% gain) 


HTTP faults : 


19 net errors, 0 proto errors, 0 retried, 9 drops 


TCP handshakes : 


405 total (48.7 req/conn) 


TCP faults : 


0 failures, 19 timeouts, 1 purged 


External links : 


24492 skipped 


Reqs pending : 


1436 


Database statistics: 


Pivots : 


1598 total, 1525 done (95.43%) 


In progress : 


42 pending, 19 init, 6 attacks, 6 diet 


"issing nodes : 


24 spotted 


Node types : 


1 serv, 34 dir, 8 file, 0 pinfo, 57 unkn, 24 par, 1474 val 


Issues found : 


611 info, 1 warn, 600 low, 740 medium, 14 high impact 


Diet size : 


333 words [333 new), 9 extensions, 256 candidates 


Signatures : 


77 total 



Figura 3-24 



Per ultimo, una vez que la prueba finalice, en el directorio 
indicado por el parametro -o tendremos un informe de resultados en 
formato HTML. Para el caso de WebGoat evaluado, skipfish ha obtenido 
los resultados que se muestran en la [figura 3-25]. 



94 



Herramientas | 3 




^ http://l27.o.o.i:So8o/ ©24 ©76 046 ©11 6165 t^l65 

Code: 200, length: 11424, declared: text/Titml, detected: application/xhtnil+xiiil, charset: ISO-8859-1 [ show trace + ] 



© Quer\- injection vector (9) 

© Shell injection vector (lo) 

Q Ser\^er-side XIVIL injection vector C5) 

O Password form submits from or to non-HTTPS page rio) 

O Directory traversal / file inclusion possible (16) 

© Interesting serv^er message (44) 

G Incorrect or missing charset (higher risk) (i) 

© Incorrect or missing MEVIE type^ (higher risk) (i) 

© XSS vector in document body (4) 

O HnVIL forai ^vith no apparent XSRF protection C46) 

FiGURA 3-25 

Ha detectado 24 vulnerabilidades de impacto alto (compromiso 
del sistema), 76 vulnerabilidades de nivel medio (compromiso de 
informacion) y 46 de nivel bajo. Adicionalmente ha creado 165 notas 
informativas. 

dQue ha detectado? Pues basicamente errores de malformacion de 
parametros: inyecciones de SQL, inyecciones de comandos, inyecciones de 
XML, path transversal, XSS y XSRF, entre otros. iEstan detectados de forma 
precisa? En general, no. 

Skipfish ha detectado que la malformacion de parametros en el 
aplicativo causa errores, es decir, ha detectado que existen errores de 
validacion; pero no ha sido capaz de afinar lo suficiente el tipo de error de 
validacion que se trata en cada ocasion. Por poner un ejempio, ha 
detectado inyecciones de SQL como XSS, XSS como inyecciones de XML, o 
inyecciones de SQL como Path Transversal. 

En conclusion: nos permite conocer que existen errores, pero no 
donde estan y cuales son exactamente. 
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Usando Arachni. 

Arachni es una herramienta automatizada de deteccion de 
vulnerabilidades web opensource que ha sido desarrollada en los ultimos 2 
anos y que nnantiene activo su desarrollo. 

Para la ejecucion de la herrannienta sobre WebGoat debennos fijar 
la cookie de sesion, mediante el parannetro cookie-string, asl conno el 
parametro exclude para evitar las URLs con dos cadenas nnuy concretas 
Logout, salida del aplicativo, y Num, que causa un error de crawling infinito. 
La [figura 3-26] nnuestra la invocacion de Arachni. 

Janachni http://localhost :8080/WebGoat/attack --cookie- 

stning='DSESSIONID=8199BFEE17B6AE153705B00244AD31D3' --exclude 
"Num" --exclude "Logout" 

Figura 3-26 

La [figura 3-27] nnuestra la ejecucion de Arachni, en este caso una 
vez la fase de crawling (deteccion de rutas del arbol web) ha finalizado y se 
estan evaluando vulnerabilidades. 



*] OS command injection (timing): Analyzing response #8354... 
*] Blind SOL injection (timing attack): Analyzing response #8328... 
*] Blind SQL injection (timing attack): Analyzing response #8319... 
^] Blind SOL injection (timing attack): Analyzing response #8317... 
*] Blind SOL injection (timing attack): Analyzing response #8316... 
*] OS command injection (timing): Analyzing response #8361... 
^] OS command injection (timing): Analyzing response #8346... 

OS command injection (timing): Analyzing response #8349... 

OS command injection (timing): Analyzing response #8344... 

OS command injection (timing): Analyzing response #8343... 
^] OS command injection (timing): Analyzing response #8341... 
^] OS command injection (timing): Analyzing response #8334... 
^] OS command injection (timing): Analyzing response #8337... 
*1 OS command injection (timing): Analyzing response #8343... 
*] OS command injection (timing): Analyzing response #8352... 
*] OS command injection (timing): Analyzing response #8358... 
*1 OS command injection (tijiiing): Analyzing response #8355... 



Figura 3-27 
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Una vez la prueba haya finalizado encontraremos un fichero con 
extension AFR (formato XML) cuyo nombre sera la fecha y hora de 
ejecucion. Ese fichero podra ser convertido a otros formatos de salida tal 
como se muestra en la [figura 3-28] para la generacion de un fichero 
HTML 



$arachni - -repload=2014-06-08\ 12.23.29\ +0200. afr --report=html 



Figura 3-28 

Tras la generacion del informe en formato HTML podremos ver 
los resultados. La [figura 3-29] muestra un subconjunto de los mismos. 



120- 



100 - 94 




Cross-Site Cross-Site Blind Path Cress-Site Operating SQL 

Request Scriprting SQL Traversal Scripting system Injection 

Forgery (XS5] Injection (?^SS]l command 

(differential in injection 

aralysrs) HTML {timing 




Figura 3-29 



El resultado es similar al de Skipfish. Arachni detecta que existen 
deficiencias en la validacion de los parametros provenientes de usuario, 
pero no es capaz de afinar exactamente de que deficiencia se trata en cada 
caso, dejando tambien otras sin detectar. 
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Usando Vega en modo automatizado 

La ultima herramienta a comparar es Vega. Una herramienta de 
codigo abierto, con un completo entorno GUI, de reciente creacion. 

Vega, ademas de funciones de revision automatizada, tambien 
puede ser usada conno proxy de auditoria, para la ejecucion de revision 
nnanual o semiautomatizada. No obstante, en este apartado lo que veremos 
sera su uso como herramienta automatizada. 



Para usar Vega como herramienta automatizada, deberemos definir 
un nuevo objetivo para un proceso de revision, tal como se indica en la 
[figura 3-30]. 



Select a Scan Target ^dfe 
Choose a target for new scan ^■^^■1 


^VEGA 


Scan Target 

(•) Enter a base URI for scan: 








://loca 1 h ost;8080/WebGoat/ atta ck?Screen = 1 0S&m en u = 5 










Figura 3-30 



Tambien podremos seleccionar los modulos a ejecutar y, en caso de 
ser necesario, definir una cookie para el proceso de autenticacion. 

En el caso de WebGoat necesitaremos definir la cookie de sesion 
JSESSIONID de la misma forma que hemos realizado en el resto de 
herramientas. La [figura 3-31] muestra el proceso de definir la cookie de 
sesion. 
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Authentication Options 

Configure cookies and authentication identity to 
u:e during scan 



Identity to scan site as 

V 

Set-Cookie or Set-Cookie2 value 



JSESSIONID=37DAA424A9Z453C336C53372BFCD4AA8 



I 

Add cookie 

FIGURA 3-31 

El resultado es el que se muestra en la [figura 3-32]. Es un 
resultado menos complete que los anteriores, donde no se detectan la 
nnayoria de las vulnerabilidades, debido a que Vega, en este aplicativo 
concreto, no ha realizado correctannente las tareas automaticas de 
deteccion de rutas y parannetros. 



O High 




(11 found] 


Cleartext Password over HTTP 


1 




Integer Overflow 


6 




Page Fingerprint Differential Detected - Possible Local 


4 




File Include 






O Medium 






O Low 




(2 found] 


Email Addresses Found 


1 




Form Pa::vvord Field with Autocomplete Enabled 


1 




O Info 




(4 found) 


X-Frame-Options Header Not Set 


4 





Figura 3-32 



®VEGA 
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Usando Vega en modo semiautomatizado 

Vega, como comentamos anteriormente, dispone de un modo de 
funcionamiento que permite, dentro de sus limitaciones, una mejora en los 
resultados: el nnodo proxy scan. 

Este nnodo nnezcia la funcion de proxy de auditoria con la funcion 
de escaner autonnatizado. Para hacer uso de ella debemos seleccionar la 
proxy, activar el servicio en el puerto 8888, redirigir nuestro navegador a 
ese puerto, activar el modo Proxy Scan y comenzar a navegar por la web. 

De esta forma todas las peticiones que hagamos seran evaluadas 
por el modulo de descubrimiento de vulnerabilidades. La [figura 3-33] 
muestra la sesion de navegacion por la web. 

<- - G D 127.0.0.1:3080AVebGoat/attack?Screen=229&menu=1100 

_ ^ choose another language: | English "r^ LoSOUt ^} 





^1^^^ Numeric SQL Injectiorl 


^B^OWASP WebGoat v5.4 


■* *■ 






S...., Restart this Lesson 

General 




^ Intercept 


^ Proxy Status 





ID 


Host 




Method 


Request 




0 


httpt/ZI 27.0.0.1 


S030 


GET 


/Web G 0 at''i m a g es/m en u_ 


Jmages/1x1_open.gif 


1 


http;//1 270.0.1 


8080 


GET 


/'Web G 0 at''atta ck?Sc reen = 


184&menu=5 


2 


httpt/ZI 270.0.1 


80S0 


GET 


/Web G 0 at''i m a g e&/ m en u_ 


Jmages/1x1_open.gif 


3 


http;//1 270.0.1 


8080 


GET 


.AVeb G 0 at''i m a g es/m en u_ 


Jmages/1x1_open.gif 


4 


http;//1 270.0.1 


8080 


GET 


fWeb G 0 at'^atta ck?Sc reen = 


229&menu=1100 


5 


http;//1 270.0.1 


8080 


GET 


/Web G 0 at 'i m a g es/m en u_ 


Jmages/1x1_open.gif 


6 


http;//1 270.0.1 


8080 


POST 


./W eb G 0 at''atta c k? Sc reen = 


229&menu=11O0 


7 


http://1 270.0.1 


8080 


GET 


,W eb G 0 at''i m a g es/'m en u. 


Jmages/1x1_open.gif 



Figura 3-33 

Tras finalizar la sesion de navegacion, veremos que hemos obtenido 
un resultado diferente, como muestra la [figura 3-34] y que tanto el 
numero como la precision de la deteccion han aumentado. 
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O High 




[21 found) 


Cleartext PaG^word over HTTP 

^f~M 1 n 1 Pr"!"! n n 

IIIJCLLIUll 

Shell Injection 

SQL Error Detected - Possible SQL Injection 
Cross Site Scripting 

Page Fingerprint Differential Detected - Possible Local 
Flip inrii iHp 

1 lit lllk.lULJt 

Possible Social Security Number Detected 
Possible Social Insurance Number Detected 


1 

2 
1 
2 

11 

1 
1 




O Medium 




[1 found] 


Local Filesystem Paths Found 


1 




O Low 




[2 found) 


Form Password Field with Autocomplete Enabled 
Email Addresses Found 


1 
1 




O Info 




[6 found) 


X-Frame-Options Header Not Set 
Cookie HttpOnly Rag Not Set 
Possible AJAX code detected 


4 
1 
1 
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Usando ZAP en modo semiautomatizado 

Como ultimo punto vamos a mostrar el uso de ZAP como 
herramienta de evaluacion semiautomatizada que nos aportara unos 
resultados muy aceptables en la deteccion de errores de validacion de 
parametros. Para ello, debemos seguir los pasos anteriormente descritos en 
la seccion de uso manual, conectando el navegador al proxy y navegando 
por la aplicacion. 

En la [figura 3-35] podemos ver, por ejennpio, la connunicacion 
interceptada por ZAP en uno de los fornnulario vulnerables a inyeccion 
numerica de SQL, a ciegas, que hay en WebGoat \formulario Blind Numeric 
SQL Injection] . 
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%^ SItios 



Scripts 



' ® l^i Sitios 

' _ L-i'lnttp://127.0. 0.1:3030 
▼ i - K'WebGoat 



'POST: attackCScreen,menu)(SUBMIT,account_n umber) 



^ Punto de intermpcion 



Inicio Rapido 



Consola de secu 



=^ Peticion 



Header: Vista Raw 



Body: Vista Raw 



POST lit t p : / / 127 . 0 . 0 . 1 : S0S0/We bGoat / attack?Screen=15 6&iiie n u =1100 HTTP > 
Proxy-Connection; keep-alive 
Content- _ength : 31 
Cache-Control: iriax-age=0 
Autiiorization : Basic Z3Vlc3Q6Z3Vlc3Q= 
Accept ; text /html, application/xlitinl+xiiiljapplicat ion /5anl;q=0. 9 , imaged 
Origin; http ; //127 . &. 9. 1 ; S080 
User -Agent; ^tozilla/5,0 (Windov^fs NT 6,2; 1^01^64) AppleWebKit/537, 36 ( 
35.0.1916,114 Safari/537.36 

Content-Type ; application/x-www-fonn-urlenccded 

Ref erer ; http : //127 . 9 . &. 1 ; 60S0/WebGoat/attaclt?Screen=156a(renu=liee 
Accept-Encoding; sdch 
Accept -Language ; es-ESjesjq=0.Bjde;q=0.6jen;q=0.4jf rjq=0. 2jid;q=0.2j 
Cookie : 3SESSIONID=SCSBS35C654EBB2414D7A3E27CC6A76E 



account nijriber=101?SUBHIT=GoJS21 



FiGURA 3-35 



Sobre ella, segun se muestra en la [figura 3-36] podemos realizar 
un escaneo automatizado. La [figura 3-37] limita el alcance una unica URL, 
evitando que se alteren los parametros de la peticion (query string), y 
linnitando la nnalformacion los parannetros enviados como parte del 
formulario POST. 



Atacar 


B 


2> Active Scan all in Scope 
J Habilitar escaneo sitio 
J Active Scan subtree 
J Active Scan single URL 


EliminarCde la Base de Datos) 
Include in Context ► 
Flag as Context ► 
Run application ► 


Active Scan advanced^^^^^^^^^^^l 



Figura 3-36 
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Advanced Active Scan 



Scope '"input Vectors 



Custom Vectors 



Policy 



Injectable Targets: 
URL Query String 

URL Path [could slow down testing) 
POST Data 

HTTP Headers [could slow down testing) 
Cookie Data (could slow down testing) 



□ 
□ 

□ 

□ 



FiGURA 3-37 

Finalnnente en la [figura 3-38] obtenennos en la seccion de alertas 
los resultados de la evaluacion autonnatizada, segun la cual se ha detectado 
una inyeccion de SQL en el parametro account_number. Una inyeccion de 
XSS en el nriismo parametro. Y finalnnente, una fuga de infornnacion en 
nnensajes de error actlvos en el aplicativo. 

De las tres vulnerabilidades identificadas para el formulario solo el 
XSS es un falso positivo. Siendo tanto la inyeccion de SQL, conno los 
nnensajes de error, vulnerabilidades correctannente detectadas. 



Alertas [3; 
▼ S Falls por Inyeccion SQL 



POST: http://1 27 . 0 . 0 . 1 : 8 0 3 0/We bG 0 at/attack?Scre en=156&menu=1100 



▼ 1^ Secuencia de Comandos en Sitios Cruzados [XSS, reflejado) 

□ POST: http://127.0.0.1:8080A'VebGoat/attack?Screen=156^;menu=1100 

▼ 1^ Application Error disclosure 

Q POST: http:/n27.0.0.1:8080A'VebGoat/attack?Screen=165&menu=1100 



URL: 

Riesgo: 
Fiabilidad: 
Parametro: 
Ataque: 



http://1 27.0.0.1 :S0S0/'.'VebGoat'attack?3creen=156&menu=11 00 

High 
Warning 

account_number 
-101 .AND -1=-! - 



Figura 3-38 
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3.6 I Conclusion 

A lo largo de este capitulo parecen evidentes las carencias que 
tienen las herramientas si insistimos en usarlas de forma totalmente 
automatizada, obteniendo resultados con abundantes falsos positivos, 
pocas identificaciones de vulnerabilidades exitosas y una cantidad muy alta 
de informacion para verificar al terminar la prueba. 

Sin embargo, tambien se muestra que en el momento que se pasa a 
un modo de trabajo semiautomatizado, como se ha visto en el caso de ZAP, 
se pueden obtienen unos resultados mucho mas precisos, con mucha 
menos informacion irrelevante y con una tasa de deteccion de 
vulnerabilidades aceptable. 

Por tanto, volvemos a recordar lo que dijimos en el primer capitulo: 
las herramientas simplifican y automatizan tareas tediosas, pero una 
correcta evaluacion de vulnerabilidades necesita de una intervencion 
manual. 
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Metodologia I 4 



Los tres primeros capitulos, que vienen a ser las primeras cien 
paginas, han servido para componer un collage donde comenzamos 
esbozando sobre que trata el asunto de las pruebas de segurldad, luego 
hemos estudlado las vulnerabilidades que mas frecuentemente aparecen y 
por ultimo ha llegado el asunto de las herramientas que tenemos a nuestra 
disposicion para descubrirestas vulnerabilidades. 

Creo que en el proceso se ha mostrado como la evaluacion de 
vulnerabilidades para ser util tiene que tener en mayor o menor medida un 
componente manual. Y ademas hemos visto que si dejamos todo en manos 
de herramientas lo que conseguiremos sera un listado de vulnerabilidades y 
errores sin mucho sentido y que probablemente termine en una papelera. 

Llegados a este capftulo cuatro pocas cosas restan para cumplir el 
objetivo marcado. Pero hay una muy basica: sintetizar todo lo visto y dar 
unas pautas elementales para una metodologia basica que nos permita 
realizar una evaluacion de vulnerabilidades aceptable acorde a nuestros 
propositos. 

No obstante, antes de tirarnos a la piscina, una aclaracion: esta 
metodologia tiene un ambito de uso interno y, por tanto, no es completa y 
ademas se evitan una serie de formalismos que una metodologia de revision 
a terceros incluiria. En consecuencia, no se nos deberia pasar por la cabeza 
afrontar una revision profesional a terceros usando esta metodologia. 

Si nos vemos, por el motivo que sea, abocados a tener que hacer 
una revision formal, mi sugerencia es que sigais la guia de un libro como 
Professional Penetration Testing. 

Este es un capitulo bastante teorico por un motivo esencial, en el 
siguiente capitulo, el quinto es donde veremos de forma practica todo el 
proceso explicado aqui. 
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Hecha esta aclaracion, vamos a pasar a los contenidos del capitulo; 
que seran los siguientes: 

• Planificacion y diseno: iPor que hacemos la prueba? iQue 
queremos obtener de ella? iQuien necesita esa informacionPiQue 
tipo de prueba vamos a ejecutar? iQue servicios debemos evaluar? 
dQue aplicativos? iExisten procesos de autenticacion? iHay 
pruebas que no debemos realizar? 

• Ejecucion, verificacion y explotacion. iQue es la recoleccion de 
informacion? iComo evaluamos las vulnerabilidades de los servicios 
de red? iY de los aplicativos web? iHasta que punto podemos 
automatizar la prueba? iQue problemas podemos encontrar? 
dComo verificamos los resultados? iY si tenemos que hacer un test 
de intrusion que hacemos? 

• Informe y gestion de vulnerabilidades. Ya hemos hecho la prueba, 
iy ahora que? iComo se comunican los resultados? i.A quien se 
comunican? iDe que forma? iQue es la gestion de 
vulnerabilidades? 
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4.1 I PLANIFICACION Y DISENO 

Sino planificamos mmimamente lo que vamos a hacer, 
trabajaremos el doble. Por tanto, antes de empezar hay que tratar una serie 
de puntos basicos: 

• Objetivos: Los puntos fundamentales sobre los que gira toda la 
planificacion: ipor que hacemos la prueba? ique queremos 
obtener de ella? dqulen neceslta esa Informacion? 

• Tipo de prueba: dDe todas las pruebas que hemos visto cual se 
adapta mejor a los objetivos? dUna prueba en caja negra? dUna 
prueba en caja gris? 

• Entorno: Segun los objetivos fijados, ddonde tenemos que llevar a 
cabo la evaluacion de la seguridad? dEn el entorno de desarrollo? 
dEn el entorno de preproduccion/pruebas? dEn el entorno de 
produccion? 

• Ubicacion: iDonde vannos a ubicar a nuestro atacante? dEn nuestra 
red interna? dEn la DMZ? dEn el exterior? 

• Memento, comunicacion y personas: dCuando debennos realizar la 
prueba? dinfluye? dDebemos informar de la prueba? 

• Afinando la prueba: dExisten vulnerabilidades que nos queremos 
evaluar? dSabemos las tecnologias de los servicios y por tanto que 
vulnerabilidades no van a afectarlos con total seguridad? dHay 
usuarios? dHay peticiones que debemos evitar? 

Objetivos 

dPor que vannos a hacer una prueba de seguridad? Esta pregunta, que quiza 
nos suene un poco a Perogrullo, es algo que tenemos que tener presente 
siempre antes de empezar. 
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El motivo es muy sencillo: trabajaremos la mitad. Nos explicamos. 
Es relativamente habitual pensar que las pruebas de seguridad son similares 
entre ellas y que, una vez tenemos los resultados de una, vamos a poder 
contestar a todas, o al menos a casi todas, las preguntas que nos podamos 
hacera posteriori, i Error! 

Las preguntas hay que hacerlas antes de empezar. Plantearlas al 
final solo servira, bien para contestar de cualquier manera, bien para tener 
que repetir la prueba. No obstante, como un ejempio vale mas que mil 
palabras, vamos a ejemplificar la situacion. 

Supongamos por un momento que tenemos una nueva version de 
una aplicacion web que queremos liberar en produccion, miAPP 2.0, y nos 
planteamos que hay que hacer una prueba de seguridad, pero pasamos por 
encima de la planificacion de los objetivos sin hacerle caso. 

El hecho es que, sin mucho criterio, decidimos hacer una prueba 
semiautomatizada de intrusion sobre el entorno de produccion en caja 
negra exclusivamente sobre el aplicativo web. 

Y entonces, leyendo los resultados, el director de desarrollo se 
pregunta: dQue resultados hemos obtenido en la verificacion de la 
seguridad de la logica?. Mientras, a su vez, el director de sistemas 
pregunta: iComo de efectiva ha sido la securizacion que hemos realizado 
sobre el servidor web Apache? 

Respuesta: no tenemos ni idea. 

Y es que, aunque tecnicamente las posibles pruebas de seguridad 
sean similares, su planificacion, disefio y resultado no lo son. 

Por tanto, antes de empezar la prueba, hay que fijar unos objetivos 
generales de la misma y, en caso de existir, unos objetivos especfficos por 
departamento/area que espere obtener resultados a partir de la prueba. 



Evaluacion de Vulnerabilidades TIC 



109 



Estableciendo objetivos 

Mas que nos gustase, no existe una varita magica que al agitaria 
genere los objetivos que necesitamos. No obstante, si hay una serie de 
preguntas basicas, que contestar nos servira para saber que es lo que 
necesitamos hacer en nuestra prueba de seguridad. 



I. dQue servicio queremos evaluar? 

II. dNecesitamos una valoracion del apiicativo? dDel apiicativo y de la 
infraestructura IT? 

III. dQueremos una valoracion que simule un atacante externo? dUn usuario del 
sistema sin privilegios? dUna prueba con el mismo conocimiento del sistema que 
tiene el personal IT? 

IV. dSe trata de un sistema que esta ya en produccion? 

v. Si se trata de un sistema que esta en produccion, dia prueba que vamos a 
realizar puede generar perdida/alteracion de informacion? 

VI. dDonde vamos a ubicar a nuestro atacante? dEn una red externa? dEn una red 
interna? 

VII. dVamos a realizar una prueba automatizada? 

VIII. En caso de realizar una prueba automatizada, dvamos a realizar descarte 
manual de falsos positivos? 

IX. dQueremos una prueba que recopile todas las vulnerabilidades existentes? dO 
una que eleve privilegios en el sistema? 

X. dExisten cuestiones especificas per areas/departamentos? 

a. dNecesitamos evaluar especificamente algun tipo de vulnerabilidad? 
dEs esa vulnerabilidad evaluable de forma automatizada? 

b. dNecesitamos evaluar la eficacia de alguna medida de seguridad 
implementada sobre el sistema? 

FiGURA 4-1 

Tipo de prueba 

En el capftulo 1 vimos, y ejemplificamos, los tipos de pruebas que 
existen y las diferencias fundamentales entre ellas. En este capitulo no 
vamos a volver a insistir en ese tema, pero si que vamos a incidir en la parte 
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practica del asunto, es decir, en elegir adecuadamente el tipo de prueba 
que necesitamos en funcion de los objetivos que hayamos fijado. 

Lo prinnero a tener claro es que tenennos a nuestra disposicion 18 
pruebas posibles, segun vemos en la [figura 4-2]. Y que estas 18 pruebas 
nos van a dar resultados diferentes, por tanto, tenennos que escoger segun 
nuestros objetivos. 



Objetivo 



Evaluacion 
Vulnerabilidades 



— Prueba Intrusion 



Automatizacion 



Automatizada 




IVIanual 



Conocimiento 
y Privilegios 



Caja Negra 



Caja Gris 



Caja Blanca 



Figura 4-2 



Las pautas para hacer la eleccion son las siguientes: 

• Evaluacion de vulnerabilidades: En principio, y para el 
cometido desde libro, esta es la prueba basica y comun a 
realizar siennpre con la intencion de obtener una recopilacion 
ordenada y priorizada de las vulnerabilidades existentes en un 
sistema. 



• Prueba de intrusion: En principio, salvo que queramos evaluar 
un sistenna de nnadurez media-alta, con medidas de seguridad 
implementadas, y previamente testado mediante evaluacion de 
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vulnerabilidades no necesitamos realizar una prueba de 
intrusion. 



• Suite automatizada: Una prueba totalmente automatizada 
sirve de muy poco. En general, come hennos visto en el capitulo 
3, cuanto mas se interviene en la prueba, mejores resultados se 
obtienen. La recomendacion, per tanto, es que minimo se 
desarrolle una prueba semiautonnatizada. 
En aquellos cases que se disponga de tiennpo y habilidad 
tecnica, se recomienda en desarrollo de pruebas manuales. 



• Conocimiento y privilegios: Una solucion intermedia en caja 
gris suele ofrecer un compromise muy adecuado entre 
esfuerzo y resultados para todo tipo de servicios. Por otra parte 
una solucion en caja negra puede ser recomendable, se adapta 
mejor a la realidad, siempre que se trate de un servicio publico 
destinado a usuarios externos. La caja blanca solo es 
recomendable para equipos expertos, donde ademas, se 
dispone de una cantidad de tiempo muy considerable. 

Entorno 



En el capitulo 1 vimos que en funcion de la fase del cicio de vida 
donde se ejecute la prueba (fase de desarrollo, fase de preproduccion o fase 

produccion) esta puede tener 
una utilidad u otra. Es decir, las 
pruebas satisfacen unos 
objetivos u otros. 



Desarrollo 




Produccion 



Preproduccion 
o Pruebas 




Esta seccion profundiza 
en ese concepto, da pautas y 
destierra algunas ideas 
erroneamente instauradas sobre 
los mismos. 
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Entorno vs. Cicio de vida 

Para profundizar, lo primero que tenemos aclarar es que existen, 
por un lado, 3 entornos donde podemos hacer pruebas de seguridad de un 
servicio y, por otro, 3 fases dentro del cicIo de vida de los servicios. Sin 
embargo, esta relacion no es uno a uno. 

Por ello, nnientras que en el entorno de desarrollo solo se hacen 
pruebas en la fase de desarrollo y en el entorno de produccion del solo se 
hacen pruebas de la fase de produccion; en el entorno de preproduccion no 
sucede lo mismo. En el entorno de preproduccion se pueden hacer pruebas 
de un servicio en fase de preproduccion o pruebas de un servicio en fase de 
produccion. 

dPor que? En resumen porque en el entorno de produccion siempre 
vamos a tener una serie de linnitaciones sobre que tipo de pruebas podemos 
hacer. Por ello, en ocasiones, las pruebas de un servicio en fase de 
produccion se ejecutan en el entorno de preproduccion. 



Entorno 


Fases 


Desarrollo 


Desarrollo 


Preproduccion 


Preproduccion o Produccion 


Produccion 


Produccion 



FIGURA 4-4 



Entorno de desarrollo: ideas base 

Vamos a enunciar los conceptos clave del entorno de desarrollo y 
como influyen en la ejecucion de pruebas de seguridad. 

■ Las pruebas a realizar en el entorno de desarrollo seran 
unicamente a servicios en fase de desarrollo. 

■ La caracteristica principal del entorno es la falta de 
homogeneidad: equipo de trabajo del propio desarrollador del 
proyecto, servidores que han quedado obsoletos... 
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■ Es el entorno menos frecuente para realizar pruebas de 
seguridad. 

■ El motivo para realizar pruebas en desarrollo es practicar una 
deteccion temprana de problemas y de errores en la 
implementacion. 

■ Es necesaria agilidad y brevedad en las pruebas. 

Entorno de preproduccion/pruebas: ideas base 

De la misma forma que hemos hecho con el entorno de desarrollo, 
ahora vamos a enunciar los conceptos clave del entorno de 
preproduccion/pruebas y como influyen en la ejecucion de pruebas de 
seguridad. 

■ Entorno que teoricamente reproduce con total fidelidad y 
exactitud el entorno de produccion. 

■ Entorno que realmente Simula la infraestructura de 
produccion: diferencias hardware, diferencias software, 
clusters, balanceadores, enrutamiento y medidas de seguridad. 

■ Doble funcion. Funcion uno: evaluacion de servicios 
previamente a paso a produccion. Funcion dos: pruebas 
posteriores a entrada en produccion. 

■ Uso previo a paso a produccion: validacion la seguridad de un 
servicio antes de la entrada del mismo en produccion. 

■ Uso en fase de produccion: comprobacion de la seguridad de 
un servicio que se encuentra ya en produccion y que por el tipo 
de prueba a realizar no puede ser ejecutada en produccion 
(riesgos de alteracion/eliminacion de informacion) 

■ Es el entorno donde ejecutaremos gran parte de las pruebas de 
seguridad. En principio todas las que no necesiten evaluar la 
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seguridad de la infraestructura ITy de las medldas de seguridad 
implementadas en produccion. 

Entorno de Produccion: ideas base 

Durante tiempo se ha considerado un error hacer pruebas en el 
entorno de produccion. Hoy dia se considera un error no usar el entorno de 
produccion. 

Mi opinion es que en el termino medio esta la virtud. Las pruebas 
en el entorno de produccion tienen un sentido y una razon de ser: el 
entorno de pruebas NO replica el entorno de produccion. 

Por tanto, la idea es que usemos el entorno de produccion cuando 
sea necesario. Ni mas, ni menos. No hace falta usarlo siempre, y mucho 
menos usarlo para actividades que se pueden hacer en preproduccion; pero 
es totalmente razonable usarlo. 

Por ello vamos a enunciar los conceptos clave del entorno de 
produccion y como influyen en la ejecucion de pruebas de seguridad. 

■ Las pruebas en produccion son esenciales ante la liberacion de un 
nuevo servicio no evaluado previamente. Ademas, pueden ser 
necesarias por otras causas: inexistencia de entorno de pruebas, 
diferencias enormes entre entornos, etc. 

■ No debemos hacer pruebas en el entorno de produccion que 
pudiesen ser hechas en el entorno de preproduccion. P.ej. 
evaluacion de vulnerabilidades de un aplicativo. 

■ Es mejor hacer pruebas de seguridad en el entorno de produccion 
cada cierto tiempo, que hacerlas cuando aparecen problemas 
serios. 

■ En mayor o menor medida se causa un perjuicio a los usuarios: 
cierre de aplicacion al usuario, etc. 
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Entorno de produccion: Buenas practicas 

En caso de tengamos que realizar pruebas en el entorno de 
produccion debemos tener en cuenta las siguientes buenas practicas. 

• Utilizar preferentemente pruebas poco agresivas. 

• Es necesario limitar el uso de herramientas automatizadas, 
priorizando el uso de pruebas manuales o semiautomatizadas. 

• Descartar el uso de pruebas que puedan denegar el servicio. 

• Limitar la insercion, eliminacion y modificacion de informacion en 
uso. Crear backups si se va a poder ver alterada informacion. 

• Las pruebas de seguridad requieren de un tiempo importante para 
su ejecucion, por tanto, sera extrarno que podamos parar el servicio 
durante la ejecucion de la prueba. Ello implica que debemos ser 
muy cuidadosos con el tipo de prueba que hacemos. 

Eligiendo el entorno adecuado: fase y prueba 

Elegir el entorno adecuado depende de una serie de factores. Los 
principales son los siguientes: los objetivos, la fase del cicio de vida en la 
que se encuentra los servicios a evaluar, el tipo de prueba que vamos a 
realizar y la adecuacion del entorno a la prueba. 



La [figura 4-5] recoge las principales pautas que hemos comentado 
a la hora de elegir entorno. 



Entorno 


CicIo de Vida 


Prueba 


Uso 


Desarrollo 


Desarrollo 


Evaluacion vulnerabilidades 


Casi nunca 


Pruebas 


Preproduccion/Produccion 


Todo tipo de pruebas 


Frecuente 


Produccion 


Nuevo servicio no evaluado 


Todo tipo de pruebas 


Muy importante 


Produccion 


Produccion 


Evaluacion vuln. no agresiva 


Segun necesidad 



Figura 4-5 
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Ubicacion del atacante 

Nuestra recomendacion general es usar la red interna siguiendo el 
esquenna de enrutanniento de la [figura 4-6] que Simula, a todos los efectos, 
un usuario desde el exterior. 




Figura 4-6 

En la figura, el equipo de pruebas se coloca en el firewall mas 
exterior del sistema. Siendo el trafico de la prueba enrutado por la red de 
acceso, como si de un usuario externo se tratase, hasta el entorno que se 
haya elegido: pruebas o produccion. 

En el caso de las pruebas en el entorno de desarrollo la falta de 
homogeneidad de este tipo de escenarios impide una recomendacion mas 
precisa. 

En caso de tratarse de aplicativos/servicios de uso interno, la 
recomendacion es colocar el equipo de pruebas en la red de usuarios 
internos y que el trafico sea enrutado hacia la red DMZ o hacia las subredes 
internas de servicios igual que sucederia con un atacante interno. 

Momento, comunicacion y personas 

El momento, sobre todo si estamos en el entorno de produccion, 
importa. Aunque seamos cuidadosos con nuestra prueba, siempre hay un 
pequeno margen de posibilidad de error. Por ello, debemos intentar 
minimizar los impactos negativos que podemos generar sobre los usuarios y 
aprovechar los momentos de baja actividad de las aplicaciones para a la 
ejecucion de las pruebas. 
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Otro punto importante es la comunicacion: tanto los responsables 
tecnicos, como los responsables funcionales de los servicios deben estar 
informados del inicio y fin de las pruebas. 

Finalmente, pero no por ello menos importantes, son los actores 
que participan en este proceso: 

■ Responsable de seguridad: Encargado de planificar y definir la 
prueba. 

■ Ingeniero de seguridad: Encargado de ejecutar la prueba. 

■ Responsables de servicios: Informados del inicio y fin de la 
prueba. Seran determinantes en la correccion de las 
insuficiencias detectadas. 

■ Gestion de Disponibilidad: Durante la ejecucion de la prueba es 
importante la monitorizacion del sistema de informacion para 
detectar de forma rapida cualquier posible indisponibilidad que 
se genere. 

Diseno final: Afinando la prueba 

En esta fase de planificacion y diseiio, el punto final de la misma, 
seria acotar y definir lo mas posible la prueba de seguridad a realizar, y para 
ello deberiamos, antes de entrar en la fase de ejecucion, hacer una 
evaluacion minima de la infraestructura a evaluar, incidiendo sobre los 
siguientes puntos: 

• Tecnologi'as usadas: Que tecnologfas son usadas en el sistema de 
informacion y por tanto son susceptibles de presentar 
vulnerabilidades. 

• Vulnerabilidades no evaluables: Que vulnerabilidades no deben ser 
evaluadas durante la prueba por determinados motivos: no ser 
adecuadas al entorno, no corresponderse con el tipo de prueba, no 
formar parte de la tecnologfa, ... 
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• Mecanismos de proteccion: Antes de comenzar, salvo que 
queramos una prueba totalmente en caja negra, es adecuado 
identificar los mecanismos de proteccion que se estan 
implementando y que deben ser evaluados. 

• Usuarios y autenticacion: Debemos valorar si es necesario algun 
tipo de autenticacion, como se realiza esta y si la prueba requiere 
de mas de un usuario para ser ejecutada correctamente. 

dQue probar automatizadamente? 

Las aplicaciones de revision automatizada tienen la virtud, o el 
defecto, segun se mire, de probar absolutamente todo lo que encuentran a 
su paso. 

Esto en principio no es erroneo, salvo cuando se realizan peticiones 
que: bien nos expulsan/cierran la sesion, bien caen en un error recursivo, 
bien pueden causar denegaciones de servicio o situaciones indeseadas. 

Per ello, antes de comenzar las pruebas definitivas, sobre todo si 
van a ser ejecutadas sobre el entorno de produccion, debemos definir que 
pruebas/peticiones no queremos que se realicen. 

Aplicativos web: dComo realizar una evaluacion adecuada? 

En el capitulo 3 hemos visto que ZAP permite un uso hfbrido donde 
la exploracion de la aplicacion la realizamos de forma manual y 
posteriormente podemos realizar sobre cada una de las peticiones una 
exploracion automatica de vulnerabilidades. 

Lo ideal, como es obvio, serfa probar todo el aplicativo 
manualmente, realizando todas las pruebas posibles que hemos visto en el 
capitulo 2 y otras mas que nos faltarian por ver. Pero no estamos en esas 
lides. 
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4.2 I EJECUCION, VERIFICACION Y EXPLOTACION 

Una vez tenemos clara la planificacion de nuestra prueba pasamos 
a la fase central del proceso de desarrollo de pruebas de seguridad: la fase 
de ejecucion de la prueba, de verificacion de vulnerabilidades y de, si 
precede, explotacion de las mismas. 

Esta fase se divide en las siguientes partes: 

• Recoleccion de informacion: La tarea de recoleccion de 
informacion se encuentra a medio camino entre el diserno y la 
ejecucion, su objetivo, ademas de detectar posibles fugas de 
informacion es verificar que la planificacion realizada 
corresponde a la realidad. 

• Evaluacion de vulnerabilidades de infraestructura: 

Dependiendo del tipo de revision a realizar esta sera la 
siguiente tarea que emprendamos. En caso de tratarse de una 
revision exclusivamente de aplicativo, no se llevara a cabo esta 
tarea. 

• Evaluacion de vulnerabilidades de aplicativo web: 

Dependiendo del tipo de revision a realizar esta sera la 
siguiente tarea que emprendamos. En caso de tratarse de una 
revision exclusivamente de infraestructura de servicios, no se 
llevara a cabo esta tarea. 

• Verificacion de resultados y explotacion: Finalmente una vez 
hemes obtenido resultados de la fase de evaluacion, debemos 
proceder con la verificacion de resultados y, si procede, con la 
explotacion de las vulnerabilidades detectadas. 

Recoleccion de informacion 

Esta tarea, tambien conocida como information gathering, consiste 
en todo el conjunto de actividades realizadas para profundizar en nuestro 
conocimiento del sistema de informacion. 
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Puede ser tan amplia y variada como queramos. Si este libro en vez 
de tratar de pruebas de seguridad para consumo interne, tratase de 
pruebas de seguridad para terceros, esta fase podria ser mucho mas amplia 
e incluir tareas como profundizar en el conocimiento del negocio, de la 
estructura empresarial, de los puntos de acceso al sistema, de los servicios 
externalizados, ... 

Sin embargo, en el nivel en el que nos movemos, vamos a intentar 
acotar la actividad a las siguientes tareas: 

• Informacion existente en Google sobre el sistema 

• Footprinting 

Google Hacking 

Nuestra tarea es hacer uso de los filtros basicos de google site, inurl 
y filetype para determinar la existencia de zonas expuestas al publico, o de 
informacion existente en el sistema y no conocida. 

Footprinting 

El footprinting, tambien conocido como deteccion de servicios y 
versiones, puede ser una tarea tambien bastante amplia: dns, snmp, icmp, 
etc. 

Para nuestra tarea acotaremos la actividad a dos tareas. 

A nivel de red y hosts usaremos de NMAP en su modo -A 
obteniendo de esta forma un conjunto completo de informacion sobre 
servicios de red, versiones de los servicios, etc. 

A nivel web, si debemos evaluar aplicativos, deberiamos comenzar 
por un crawling del aplicativo y por una deteccion de rutas con WIKTO o 
herramienta similar. 
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Evaluacion de vulnerabilidades en infraestructura IT 

La deteccion de vulnerabilidades a nivel de red o de hosts puede 
realizarse segun lo que hemos visto en el capitulo 3 de forma manual o 
automatizada. 

Esta actividad es optativa dependiendo del alcance de la revision 
que estemos realizando. 

En case de que sea una tarea a realizar la recomendacion general es 
hacer uso de una revision semiautomatizada. 

Una buena forma de comenzar es conectando a los servicios en 
crudo, haciendo uso de netcat o socat y comprobar que efectivamente los 
servicios se corresponden con la informacion recibida por Nmap. 

Una vez hecho esto, al nivel en el que nos movemos, el siguiente 
paso deberia ser lanzar un escaner automatizado, ajustado con mucho 
cuidado la profundidad y los modulos de revision usados. Es decir, si 
estamos evaluando un sistema Linux, no necesitamos hacer pruebas para 
sistemas Windows, ni Solaris. De la misma forma que si es un sistema que 
tenemos completamente actualizado a nivel de parcheo, podemos obviar 
los modulos que detecten vulnerabilidades en base al versionado. 

Respecto a los resultados automatizados recomendamos contrastar 
la informacion de, al menos, dos escaneres automatizados. 

Evaluacion de vulnerabilidades en aplicativo web 

La deteccion de vulnerabilidades a nivel de aplicativo puede 
realizarse segun lo que hemos visto en el capitulo 3 de forma manual o 
automatizada. 

Esta actividad es optativa dependiendo del alcance de la revision 
que estemos realizando. 

En caso de que sea una tarea a realizar la recomendacion general es 
hacer uso de una revision semiautomatizada. 
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Una buena forma de comenzar es conectando con nuestro 
navegador a las rutas detectadas en la fase de footprinting y de recoleccion 
de informacion en google, en muchas ocasiones nos sorprenderemos de lo 
que podemos llegar a encontrar: errores de configuracion, ficheros con 
informacion sensible, etc. 

El siguiente paso consistirfa en realizar la revision manual de los 
elementos basicos que siempre que sea posible serfa conveniente revisar 
manualmente con la intencion de extender y completar a las herramientas: 

^ Validacion de formularies: La tarea consiste en elegir un formulario 
de los existentes en el aplicativo y someterlo a una revision manual 
de validacion. 

^ Validacion de parametros de navegacion: La tarea consiste en 
identificar los parametros de navegacion (enviados en la URL) y 
someterlos a una revision manual de validacion. 

^ Control de la autenticacion: La tareas consiste en verificar el 
acceso a una URL autenticada sin autenticacion, controlar el cierre 
efectivo de la sesion y garantizar la seguridad de las cookies. 

^ Control de autorizacion: La tarea consiste en verificar el control de 
acceso a una URL para la que no se tienen privilegios de acceso, asi 
como verificar la existencia de mecanismos anti-CSRF. 

Finalmente, una vez hecho esto, al nivel en el que nos movemos, el 
siguiente paso deberfa ser lanzar una revision automatizada, ajustado con 
mucho cuidado la profundidad y los modulos de revision usados. 

Respecto a los resultados automatizados recomendamos contrastar 
la informacion de, al menos, dos escaneres automatizados. 
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Verificacion de resultados v explotacion 

El ultimo punto de esta fase es, con diferencia, el menos 
sistematico, puesto que depende por completo de la informacion 
proporcionada por las herramientas que hayamos usado. 

La idea general no es otra que, con la informacion del capftulo 2 y 
con la propia informacion dada por la herramienta, chequear la existencia 
de la vulnerabilidad. 

El metodo mas comun para esta tarea es la revision manual con 
inspeccion visual de resultados. 

Para ello, dado que las herramientas automatizadas suelen mostrar 
la peticion realizada y la respuesta recibida, nuestra tarea sera repetir esa 
misma peticion ejecutada por la herramienta automatica y confirmar que el 
resultado que se produce evidencia la existencia de una vulnerabilidad. 

Finalmente, si el tipo de revision que estamos llevando a cabo lo 
exige se puede proceder a la explotacion de la vulnerabilidad, bien 
mediante el uso de exploits publicos, bien mediante el uso de herramientas 
especificas (metasploit, sqimap, the hydra, ...) o bien mediante el desarrollo 
de nuestro propio exploit. 

^ OBSERVACION 4-1 - Vulnerabilidades por versiones 
desactualizadas. 

En el caso de vulnerabilidades dependientes de versiones 
desactualizadas de software, la recomendacion general es, si no vamos 
a llevar a cabo explotacion de las mismas que garantice su existencia, 
indicarlotal situacion una "observacion". 

No se recomienda asegurar la existencia de una vulnerabilidad por 
versiones desactualizadas hasta que no se verifique el nivel de parcheo 
real del sistema o hasta que no se explote de forma efectiva la 
vulnerabilidad. 
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4.3 I INFORME YCORRECCION DE VULNERABILIDADES 

El ultimo punto, del proceso, pero no por ello menos importante es 
el acto de comunicar la vulnerabilidad y gestionar adecuadamente su 
correccion o mitlgaclon. 

Para nuestro proposito, aunque nos movamos en un annbito 
Interno, el Informe debe tener un nnininno de calidad y legibilidad. Si nos 
limitamos a copiar y pegar los resultados de las herrannientas autonnatizadas 
es muy posible que los destinatarios de los informes dediquen el mismo 
tiempo a su lectura que nosotros a su redaccion. 

Por ultimo, una vez hemos informado del resultado el proceso se 
ramifica en funcion de quien sea el destinatario de este informe. Veremos 
los casos mas comunes. 

Redactar un informe 

Un informe aceptable para uso interno debe contener un mmimo 
de informacion elaborada y una estructura similar a la siguiente 

• Objetivo y Alcance: Breve descripcion de los objetivos 
planificados y de los servicios evaluados. 

• Resumen Ejecutivo. Resumen de los resultados generales de la 
prueba detallando: 

■ La valoracion cuantitativa del proceso realizado. Es 
decir el numero de vulnerabilidades segun nivel de 
impacto (informativo/bajo/medio/alto/critico). 

■ El listado de deficiencias encontrado. 

• Detalle de vulnerabilidades: Grueso del informe donde se 
recopilan cada una de las vulnerabilidades encontradas 
detallando, al menos, los siguientes aspectos: identificador, 
descripcion, evidencia, valoracion de riesgo y recomendacion. 



Evaluacion de Vulnerabilidades TIC 



125 



El proceso de correccion de vulnerabilidades 

La correccion de las vulnerabilidades, o su mitigacion en caso de 
que no puedan ser subsanadas, es el fin ultinno de las pruebas de seguridad. 

No obstante, para comprender mejor que implica la correccion de 
vulnerabilidades debemos entender que el proceso de pruebas de 
seguridad puede tener como cliente a otros dos procesos: el propio proceso 
de gestion de la seguridad, o bien el proceso de gestion de la entrega, en 
funcion del punto del cicio de vida del desarrollo en el que nos 
encontrennos. La [figura 4-7] \o ejemplifica. 




Ejecucion, 
Verificacion Y Planificacion 
Explotacion yDiseno 




Figura 4-7 
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Las repercusiones seran muy diferentes en funcion de que proceso 
sea el cliente de las pruebas de seguridad. 

Detectar una vulnerabilidad en fase de pruebas de una entrega 
implicara rechazar su despliegue en produccion y volver a la fase de 
implennentacion para corregir las vulnerabilidades detectadas. Es, por 
decirlo de alguna forma, una tarea interna de la gestion de la entrega 
englobada dentro de lo que se puede entender como Quality Assurance. 

En este caso, el infornne llegara al responsable de la entrega y sera 
este el que distribuya las tareas de correccion de las vulnerabilidades 
detectadas entre los tecnicos que han implementado esa entrega. 

Sin ennbargo, la deteccion de vulnerabilidades cuando el cliente del 
proceso es las gestion de vulnerabilidades que forma parte de cualquier 
proceso de gestion de la seguridad es una situacion totalmente distinta. 

En este caso lo que se habra encontrado son vulnerabilidades sobre 
un sistema en produccion que esta siendo usado. En estos casos los pasos a 
dar son los siguientes: 

• Comunicacion de resultados: Con las vulnerabilidades y sus 
riesgos identificados, analizadas y priorizadas el responsable de 
seguridad debera comunicar a los responsables de los servicios 
afectados los resultados del proceso y sus recomendaciones. 

• Valoracion del riesgo: Los responsables de servicios afectados 
deberan valorar el riesgo del sistema de informacion. Se 
deberan valorar que vulnerabilidades pueden y deben ser 
corregidas, cuales seran mitigadas y cuales se mantendran sin 
corregir aceptando el riesgo derivado. 

• Definicion de acciones correctivas: Los responsables de los 
servicios deberan definir en colaboracion con el personal 
tecnico las acciones concretas a emprender para corregir las 
vulnerabilidades. 
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• Gestion de cambios: Se gestionaran todos los cambios 
necesarios para implementar las acciones correctivas. 

• Reevaluacion: Una vez finalizada la implementacion de cada 
accion correctivas, como parte de la propia gestion de entrega, 
realizara una reevaluacion para verificar que han sido 
correctannente subsanadas. 

La [figura 4-8] muestra el proceso de correccion de una 
vulnerabilidad dentro del proceso de gestion de vulnerabilidades. 



Comunicacion 



Resultados 




Deficion 
Acciones 
Correctivas 




Gestion de 
Cambios 



Figura 4-8 
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4.4 I Resumen grafico 

La [figura 4-9] sirve como resumen final de todo el capitulo. Un 
grafico que sintetiza la metodologia basica explicada. 
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Figura 4-9 
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Para finalizar este libro, despues de un capitulo 4 eminentemente 
teorico, este caso practice sirve como gran ejempio de todo lo que hemos 
contado en el. En el capitulo se expone un proceso completo de revision 
sobre un aplicativo web y el sistema asociado al mismo, con la unica 
salvedad de la fase de correccion de vulnerabilidades. 

Advertencia: mejorar la legibilidad final de cada pagina impide la 
numeracion de tablas yfiguras en este capitulo. 

5.1 I PLANIFICACION Y DISENO 
Cuestionario de obietivos 

I. dQue servicio queremos evaluar? 

Servicio de docencia virtual basado en Moodle. El servicio esta alojado 
en un sistema CentOS 6.5 ejecutandose bajo una infraestructura LAMP 
(Linux, Apache, MySQL y PHP) con IP 192.168.1.102 

II. cNecesitamos una valoracion del aplicativo? dDel aplicativo y de la 
infraestructura IT? 

De ambas partes. 

III. dQueremos una valoracion que simule un atacante externo? dUn 
usuario del sistema sin privlleglos? cUna prueba con el mismo 
conocimiento del sistema que tiene el personal IT? 

Queremos simular un usuario de sistema sin privilegios de acceso. 

IV. iSe trata de un sistema que esta ya en produccion? 



No. 
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V. Si se trata de un sistema que esta en produccion, dla prueba que 
vamos a realizar puede generar perdida/alteracion de informacion? 

N/A 

VI. cDonde vamos a ubicar a nuestro atacante? dEn una red externa? 
cEn una red interna? 

En red local. 

VII. tVamos a realizar una prueba automatizada? 

Hibrida. Automatizada en su mayor parte, con revision manual de 
algunos aspectos del aplicativo. 

VIII. En caso de realizar una prueba automatizada, dvamos a realizar 
descarte manual de falsos positivos? 

Si, se van a descartar falsos positivos. 

IX. dQueremos una prueba que recopile todas las vulnerabilidades 
existentes? iO una que eleve privilegios en el sistema? 

Queremos una recopilacion de vulnerabilidades. 

X. cExisten cuestiones especi'ficas por areas/departamentos? 
No. 

Prueba planificada 

En base a la informacion y al cuestionario de objetivos se determina 
por parte del responsable de seguridad realizar las siguientes acciones: 

• Una evaluacion automatizada en caja negra de la infraestructura 
LAMP. Sin privilegios de acceso. 

• Una evaluacion semiautomatizada en caja gris del aplicativo web 
Moodle. 
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Dado que se trata de un sistema que no esta en uso, se acuerda 
verificar la version final desplegada en el entorno de produccion, como 
peso previo a su liberacion a los usuarios. 

Se descarta el uso del sistema de preproduccion puesto existen 
diferencias en la infraestructura LAMP existente en el. 

La prueba se llevara a cabo desde la red local, simulando ser un alumno 
del sistema de informacion. 

Se contaran con credenciales de acceso basicas a la plataforma Moodle 
con el usuario "alumno". 

De la navegacion por la aplicacion identificamos una peticion que no 
debe realizarse dado que finalizara la sesion en curso: 

http://192. 168.1. 102/moodle/login/logout.php?sesskey= 

No parece que existan otras peticiones que finalicen la sesion. 

Por ultimo, se revisara manualmente: 

a) La validacion de parametros en el formulario de creacion de 
POSTS del BLOG alumno. 

b) La validacion de parametros en el identificador ID de las 
peticiones moodle/course/ view.php ?id=3 

c) El control de autenticacion en el acceso a 
moodle/ mod/ page/ view.php ?id=78 

d) El control de autorizacion en el acceso a la funcion 
administrativa moodle/admin/user.php 
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5.2 I Ejecucion 

Recopilacion de informacion 

El sistema no se encuentra indexado por Google. 

La ejecucion de NMAP devuelve la siguiente informacion. 



# nmap -n -A -sS -P0 192.168.1.102 

Starting Nmap 6.00 ( http://nmap.org ) at 2014-06-11 19:08 CEST 

Nmap scan report for 192.168.1.102 

Host is up (0.00032s latency). 

Not shown: 996 closed ports 

PORT STATE SERVICE VERSION 

21/tcp open ftp vsftpd 2.2.2 

I ftp -anon: Anonymous FTP login allowed (FTP code 230) 

|_drwxr-xr-x 2 0 0 4096 Mar 01 2013 pub 

22/tcp open ssh OpenSSH 5.3 (protocol 2.0) 

I ssh-hostkey: 1024 e9:58:f8:59:c4:5f :6a:03:c7:f7:48:e9:3a:a3:88:b7 (DSA) 
|_2048 25:b2:52:ae:85:f5:c6:9a:93:ac:ff :32:96:44:d4:8e (RSA) 
80/tcp open http Apache httpd 

|_http-methods : No Allow or Public header in OPTIONS response (status code 
200) 

|_http-title: Bitnami Moodle Stack 

443/tcp open ssl/http Apache httpd 
I ssl-cert: Subject: commonName=mintlab 
I Not valid before: 2014-05-20 16:32:11 
|_Not valid after: 2024-05-17 16:32:11 

|_http-methods : No Allow or Public header in OPTIONS response (status code 
200) 

|_http-title: Bitnami Moodle Stack 

MAC Address: 08:00:27:E6:38:53 (Cadmus Computer Systems) 

Device type: general purpose 

Running: Linux 3.X 

OS CPE: cpe: /o: linux: kernel: 3 

OS details: Linux 3.0 - 3.1 

Network Distance: 1 hop 

Service Info: OS: Unix 



TRACEROUTE 

HOP RTT ADDRESS 

1 0.32 ms 192.168.1.102 



OS and Service detection performed. Please report any incorrect results at 
http://nmap.org/submit/ . 

Nmap done: 1 IP address (1 host up) scanned in 15.13 seconds 
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Podemos ver que se trata de un sistema Linux, como ya sabiamos. 
Erroneamente identificado con kernel 3.x, dado que Centos 6.5 sigue en un 
kernel 2.6.x 

Los servicios desplegados en el publicamente son: 

FTP: vsftpd 2.2.2 con acceso anonimo habilitado. 
SSH: OpenSSH 5.3 

HTTP/HTTPS: Apache, sin informacion de versionado. 
Segun informa el sistema se trata de un servicio Bitnami 
Moodle Stack. 

La conexion directa a los servicios confirma la informacion 
disponible. 

# nc 192.168.1.102 21 
220 (vsFTPd 2.2,2) 

# nc 192.168.1.102 22 
SSH-2.0-OpenSSH_5.3 

# nc 192.168.1.102 80 
HEAD / HTTP/1.0 

HTTP/1.1 200 OK 

Date: Wed, 11 Jun 2014 17:18:01 GMT 
Server: Apache 
X- Frame-Options: SAMEORIGIN 
Accept- Ranges: bytes 
Vary: Accept-Encoding 
X-Mod-Pagespeed: 1.7.30.4- 
Cache-Control: max-age=0, no-cache 
Content- Length: 5413 
Connection: close 

Content-Type: text/html; charset=UTF-8 

# nc 192.168.1.102 80 
GET /moodle/ HTTP/1.0 

HTTP/1.1 200 OK 

Date: Wed, 11 Dun 2014 17:19:16 GMT 
Server: Apache 
X- Frame-Options: SAMEORIGIN 
X-Powered-By: PHP/5.4.28 

Set-Cookie: MoodleSession=cos4377u4ca5uchi2icvgj9nk6j path=/ 
Cache-Control: max-age=0, no-cache, no-store, must-revalidate, 
post-check=0, pre-check=0 
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Pragma: no-cache 
Vary: Accept-Encoding 
X-Mod-Pagespeed: 1.7.30.4- 
Content-Length : 3368 
Connection: close 
Content-Type: text/html 

Ademas la peticion de una pagina servida por PHP nos muestra 
informacion adicional: 

X-Powered-By: PHP/5.4.28 

Set-Cookie: MoodleSession=cos4377u4ca5uchi2icvgj9nk6j path=/ 
Cache-Control: max-age=0j no-cache^ no-store^ must-revalidate, 
post-check=0j pre-check=0 
X-Mod-Pagespeed: 1.7.30.4- 

La version de PHP que encontramos en el sistema es la 5.4.28, 
existen directivas de seguridad sobre cookies (aunque el path de las cookies 
deberia estar restringido al directorio /nnoodle) y se usa el modulo 
MOD_PAGESPEED de Apache 2. 



Analisis automatizado de infraestructura LAMP 



Para el analisis autonnatizado vannos a comenzar usando Nexpose. 



start Usvj Scan 



Site Moodle 
Site Details 



Scan template Full audit without Web Spider 



included assets 192168 1 102 



Excluded assets 



IVIanual Scan forgets 



You can scan ore or more assets within this site by entering IP addresses, IP address ranges or 
host names. 



® Scan all assets within this site 

O Specily one or more assets within this site to scan 

Assets to scan 
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Memos seleccionado un test bastante extenso (auditoria completa sin web) 
Los resultados obtenidos han sido los siguientes: 



X.509 Certificate Subject CN Does Not Matcli tlie Entity Name 
l=TP server does not support AUTH command 
Weals Crypto grapliic Key 
FTP access with ftp account 
l=TP access witin anonymous account 
Seif-signed TLS/SSL certificate 
TCP Sequence Number Approximation Vuinerabiiity 
Open SSL SSUTLS MiTM vuin erabiiity [CVE-20 14-0224 ) 
ICMPtimestamp response 
TCP timestamp response 



El siguiente analisis lo realizaremos con OpenVAS, en este caso 
inhabilitaremos una cantidad importante de plugins, dejando unicamente 
aprox. 3000 comprobaciones de las mas de 12000 existentes: eliminaremos 
todas las comprobaciones locales, todas las comprobaciones de sistemas 
Unix distintos a Linux, todas las comprobaciones de sistemas Windows, etc. 



Selection de complementas- 



Nombre 


|Avi»] jActtvo 


± AIX Local Secjrtty Checks 


□ 


±1 Brute force attacks 


□ 


±i Buffer overflow 


□ 


±1 Centos Local Security Checks 


n 


±1 CISCO 


□ 


i+] Credentials 


□ 


±1 Databases 


□ 


3 Debian Local Security Checks 


n 


3 Default Accounts 


a 


±\ Denial of Service 


□ 


±1 Fedora Local Security Checks 


□ 


3 Hnger abuses 


□ 


■3 firewalls 


□ 


+1 FreeESD Local Security Checks 


□ 


±1 FTP 


a 


±1 Gain a shell remotely 


o 


+' General 


□ 


±1 Gentoo Local Security Checks 


n 


3 HP-UX Local Security Checks 


□ 


+1 Mac OS X Local Security Checks 


□ 


±1 Halware 


□ 


+1 Mandrake Local Security Checks 


□ 


±1 Netware 


m 



12159 complementos; 2989 acttvos 
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Sondeando la r&d desde localhost 




- + 


X 




Nombre de 5i5tema Anallsis de p jertos Comprobacione5 Parar 






M 192-168. 1 102 1 1 4 % 


□ 
















Parar toda la prueba | 





La unica vulnerabilidad reportada por OpenVAS es la existencia de 
un FTP anonimo. 



Informe para el ambito: Evaluacion LAMP - Moodle (Tarea: Moodle) 


Comentarios Opcione5 Informe 




Slstem^/Puerto/CrltlcMBd J 
El A 192.163,1.102 
- i general/tcp 

^ Security Note 
^ Log Message 
(3 P 55h (22/tcp) 
S P https {443/tcp) 
D 9 http (QO/tcp) 
[+) P general/lcmp 
a P ftp (21/tcp) 
S general/CPE 


Reportado por NVT "AnonymouB FTP Checking" (1.3. 6. 1.4. 1.25623. 1.0. 900600): 

Overview: 

This FTP Server allows anonymous logins. 

A host that provides an FTP service may addttionally provide Anonymous FTP 
access as well. Under this arrangement, users do not strictly need an account 
on the host. Instead the user typically enters 'anonymous' or 'ftp' when 
prompted for username. Although users are commonly asked to send their email 
address as their password, little to no verification is actually perfomned on 
the supplied data. 

Solution: 

If you do not want to share tiles, you should disable anonymous logins. 
Risk factor : Medium 
Here are the contents of the remote FTP directory listing: 
drwxr-xr-x 2 0 0 4096 Mar 01 2013 pub 

CVE : CVE-1999-0497 
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Analisis manual de aplicativo WEB 

Validacion formulario BLOG 

La validacion de parametros en el formulario de creacion de POSTS del 
BLOG alumno (http://192.168.1.102/nnoodle/blog/edit.php) se ha verificado 
de forma exhaustiva, tanto de forma manual como semiautomatizada, 
realizandose un total de mas de 500 peticiones esa URL el resultado es el 
siguiente. 



T ^ AJertas (4) 



► 1^1=^ Cookie set without HttpOnly flag (2) 

► 1^ Ri Password Autocomplete in browser 
^ Ij^ 1- Private IP disclosure [19) 

► l^X-Content-Type-Options header missing (37) 



Validacion URLde navegacion ID 

La validacion de parametros en el parametro ID utilizado en la navegacion 
por el aplicativo (Ej: /moodle/course/view.php?id=3) ha sido verificado de 
forma exhaustiva, tanto de forma manual como automatizada, realizandose 
un total de mas de 500 peticiones esa URL el resultado es el siguiente. 



▼ S^lertas [2) 

► S Private IP disclosure (2) 

> ft l^X-Content-Type-Options header missing (3) 
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Control de la autorizacion 

La peticion directa del recurso administrativo /admin/user. php es 
correctamente controlada por el sistema, denegando el acceso a un usuario 
sin privilegios. 



Esto NO implica que otro recursos administrativo o funcion sea 
controlado correctamente. 



D 192.16S.1.102/moodle/admin/user.php 


myleam.COm English (en)' 


MyLearn.com 






Home 






NAVIGATION 




Access denied 


Home 




Uore information about thi& error 



Se verifica igualmente que la cookie de sesion generada no es 
secuencial y que la finalizacion de la sesion se realiza de forma adecuada. 

Control de la autenticacion 

La peticion directa del recursos con acceso autenticado 
moodle/mod/page/view.php?id=78 ha sido controlada de forma 
satisfactoria. 

Esto NO implica que otro recurso autenticado sea controlado 
correctamente. 

Se verifica la existencia de un campo SessKey existente como parte 
de las peticiones que controla la posibilidad de realizar CSRF. 
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Q 1 92.1 68.1 .1 02/moodle/login/index.php 

mylearn.com Engiisn (en)- 



MyLearn.com 

Home Log in to the site 

Log in 



Username | j 

Password I I I Login ^ 



Analisis automatizado de aplicativo WEB 

El analisis automatizado del aplicativo WEB ha sido realizado con 
ZAP (Zed Attack Proxy). 



^ 1 92. 1 68. 1 . 1 02 :80 Sea n P rog ress 



PI u gin 


Strength 


Progreso 


Elapsed 


Est.. 


Path Traversal 


Bajo 




04:01.097 




Remote File Inclusion 


Bajo 




00:58.142 




Server side include 


Bajo 








Secuencia de Comandos en Sitios Cruzad... 


Bajo 








Gross Site Scripting (Persistent) 


Bajo 








Falla porlnyeccion SQL 


Bajo 








Server Side Code Injection Plugin 


Bajo 








Remote 03 Command Injection Plugin 


Bajo 








Directory' browsing 


Bajo 








Secure page browser cache 


Bajo 








External redirect 


Bajo 








CRLF injection 


Bajo 








Parametertampering 


Bajo 








Cross Site Scripting (Persistent) - Prime 


Bajo 








Cross Site Scripting (Persistent) - Spider 


Bajo 








Script active scan rules 


Bajo 








Total elapsed time 


05:00.668 








Total number of requests 


3782 











Cerrar 
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El resultado de la evaluacion es el siguiente: 



▼ S ^ Secuencia de Comandos en Sitios Cruzacfos (XSS, reflejatlo) [S) 

Ql POST: http://192.168.1.102/moodle/calendar/event.php 
D POST: http://192.16S.1.102/moodle/calendar/event.php 
Q POST: http://192.16S.1.102/moodle/calendar/event.php 
Q POST: http://192.168.1.102/moodle/calendar/event.php 
Q POST: http://192.168.1.102/moodle/calendar/event.php 
D POST: http://192.16S.1.102/moodle/calendar/event.php 
D POST: http://192.168.1.102;moodle/calendar/event.php 
Q POST: http://192.168.1.102;moodle/calendar/event.php 

▼ S ^ Directoi7 browsing (2) 

Q GET: http://192.168.1.102ymoodle/lib/ajaxy 
Q GET: http://192.168.1.102/moodle/repository/ 

▼ ft Password Autocomplete in browser 

Q GET: http://192.168.1.102ymoodle/login/index.php 

► ft fi3 Private IP disclosure (28) 

^ ft ^ X-C 0 nte nt-Tvp e-0 pti o n s lieader missing f28) 

► ft piX-Frame-Options lieader not set (2) 
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5.3 I Verificacion 



Certificado X.509 no corresponde con el sistema 

Nexpose ha notificado de ello correctamente. El certificado se 
verifica emitido para "mintlab" mientras que el sistema es 192.168.1.102 



Visor de certificados:'*mintlab" 






General Detalles 




No se pudo verifkar este certificado porque no se confta en el emeor 




Emitido para 

Nombre comun (CN) ^^^^ 

Organizacion (0) <No es parte de un certificado> 
Unidad organizativa (OU) <No es parte de un certificado 
Nurrero de serie OftAC:B5;B5;BB:54;9F;35;53 



Certificado X.509 esta autofirmado 

Nexpose ha notificado de ello correctamente. 



Emitido para 

Nombre comun (CN) mintlab 

Organizacion (0) <No es parte de un certificado> 

Unidad organizativa (OU) <No es parte de un certificado> 

Numero de serie 00:AC:B3:B6;BB:54:9F:85:63 

Emitido pK>r 

Nombre comun (CN) mintlab 

Organizacion (0) mintlab 

Unidad organizativa (OU) <No es parte de un certificado> 
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Clave criptografica debil 

Nexpose ha notificado de ello correctamente. En las propiedades 
del certificado se puede ver que es un certificado RSA con una clave de 1024 
bits. Actualnnente la recomendacion pide que los certificados RSA se emitan 
con clave de 2048 bits. 

Servicio FTP con acceso anonimo habilitado 

Nexpose ha notificado de ello correctamente. Verificamos que 
efectivamente existe un servicio FTP habilitado con acceso anonimo. 



onnected to 192 . 168 . 1 . 
28 (vsFTPd 2.2.2) 
ame ( 192 . 168 . 1 . 182 : roo 
31 Please specify the 
assuord : 

38 Login successful, 
emote system type is U 
sing binary mode to tr 




Prediccion de secuencia TCP 

Falso positivo de Nexpose. A priori segun la informacion 
proporcionada por NMAP es un falso positivo. 



CP Sequence Prediction: D if f icu Ity =257 (Good luck?) 



Vulnerabilidad SSL MITM (CVE 2014-0224) 



Desconocemos el nivel de actualizacion del sistema y no se va a 
realizar explotacion efectiva, se notificara como informacion. 
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XSS en Moodle 

ZAP ha notificado un posible XSS. Al proceder a verificarlo vemos 
que el vector que ha sido notificado como falso positivo es ;alert(l); sin 
embargo el vector es inyectado dentro de codigo HTML y no dentro de 
codigo JS. Por tanto, nunca va a poder ser explotado. 

Se trata pues de un falso positivo. 

iampjtime-14e2470eee#event_455\">eW45pz4p<\/a><\/div><div><iing alt=\"\" class- V'smalliconV title=\"V src-V"http:\/\/192.16B. 1, ie2\/i 
3e603599\/i\/u5erevent\" \/><a href-\"http i \/\/192 , 16B. 1 . 162\/iiK3odle\/calendar\/view. php?cour5e=3&ampi view-dayaanpjtime=14e2470&0e#ev 
"\" cla55=\"5mallicon\" title=\"\" 5rc=\"http ; \/\/192, 16B, 1. ie2\/iiioodleN/thene\/image, php\/clean\/core\/140e6e3599\/i\/u5erevent\" \/ 
\/calendar\/view,php?course=3&ampiview=day&tiine=1492470e00#event_456\">alert(l)j<\/a><\/div><div><iing alt=\"\" class=\"smallicon\ 
\,/inoodle\/theme\/image. php\/clean\/core\/14ee603599\/i\/userevent\" \/><a href=\"http:\/\/192. 16S . 1. 102\/moodle\/calendar\/view. php?c- 
2vent_201\">te5t<\/a><\/div><div><iing alt=\"\" class=\"smallicon\" title=\"\" src=\"http;N/\/192. 16S. 1 . 102\/moodle\/the(i?e\/ image . php\ 
\/><a href=\"http ; \/\/192. 168. 1, ie2\/moodle\/calenda'-\/view. php?course=3&ampiview=dayaampiti!re=14B247eae8-#event_457\">;alert(X);<\/a> 





on pretfefinida 


^ Fuzzer [ [fl Parametros | ^ Http Sessions | w Res ultadas Zest | 't^i Clients | ^ WebSockets | 


:^/UAX Spider | 


L J Salida 






Secu&ncia deComandos en Sitios Cruzados (XSS, reflejado) 




URL 


http:/j'192.168.1.102/moodle/calendar/event.php 








Riesga: 

Fiabilidad: 

Parametro: 

Ataque: 

Evidencia: 

CWEId: 

WASC Id: 


l^> High 

Warning 

instance 

;alert(1); 

;alert[1); 

79 

8 







Indexacion de directorios en Moodle 

Se verifica que los directorios /moodle/lib/ajax y 
/moodle/repository son indexables. 



Index of /moodle/lib/aj 

• Parent Directory 

• ajaxlibphp 

• blocks_plip 

• getnavbranch.php 

• getsiteadminbranch-php 

• setuserpref-pho 



Index of /moodle/repositorj' 

• Parent Directory 

• README .Txt 

• al&esco ' 

• areaflles.' 

• boxflef' 

• course file 5.' 

• draftfiles aiax.php 

• draftfiles matiager.php 
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5.4 I INFORME 
Objetivos v alcance 

En base a la informacion y al cuestionario de objetivos se determina por 
parte del responsable de seguridad realizar las siguientes acciones: 

• Una evaluacion automatizada en caja negra de la infraestructura 
LAMP. Sin privilegios de acceso. 

• Una evaluacion semiautomatizada en caja gris del aplicativo web 
Moodle. 

El sistema evaluado se encuentra sobre el host 192.168.1.102 
Los servicios evaluados en esta revision han sido: 

■ Servicio FTP en el puerto 21/TCP 

■ Servicio HTTP en el puerto 80/TCP 

■ Servicio HTTPS en el puerto 443/TCP 

El unico aplicativo web evaluado ha sido Moodle localizado en 
http://192.168.1.102/moodle 



Resumen cuantitativo 



Subsistema 


Infornnativo 


Bajo 


Medio 


Alto 


Critico 


FTP 


0 


1 


0 


0 


0 


HTTP 


0 


0 


0 


0 


0 


HTTPS 


1 


1 


0 


0 


0 


Aplicacion Moodle 


0 


1 


0 


0 


0 


Totales 


1 


3 


0 


0 


0 
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Listado de vulnerabilidades 



Codigo 


Nombre 


Nivel 


Subsistema 


INF-01 


SSL MITM (CVE 2014-0224) 


Informativo 


HTTPS 


VUL-01 


FTP anonimo habilitado 


Bajo 


FTP 


VUL-02 


Deficiencias certificado X.509 


Bajo 


HTTPS 


VUL-03 


Indexacion de directories 


Bajo 


IVIoodle 



Detalle de resultados 



INF-01: SSL MITM (CVE 2014-0224) 

■ Detalle: OpenSSL con versiones anteriores en cada una de sus 
ramas a 0.9.8za, 1.0.0m y 1.0. Ill no restringe adecuadamente el 
procesanniento de los nnensajes ChangeCipherSpec, pernnitiendo 
ataques nrian-in-the-middle, el secuestrar sesiones y la obtencion de 
informacion sensible. 

■ RIesgo: No se valora puesto que se desconoce si el sistema se 
encuentra parcheado contra esta vulnerabilidad. 

■ Recomendacion: Verificar el adecuado nivel de parcheo del 
sistema contra esta vulnerabilidad. 

VUL-01: FTP ANONIMO HABILITADO 

■ Detalle: Se ha detectado la existencia de un FTP anonimo 
ejecutandose en el puerto 21/TCP. 

■ Evidencia: 



:Gnnected to 192.168.1.182 ( 
ZZQ (vsFTPd 2.2.2) 
lame ( 192 . 168 . 1 . 182 : root ) : e 
331 Please specify the passi 
'assword : 

?3B Login successful, 
demote system type is UNIX. 
Jsing binary mode to transfe 

■ tp> 



92.168.1.182) . 

lonymous 
ird . 



files. 
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■ Riesgo: Bajo. Potenciales fugas de informacion o mal uso. 

■ Recomendacion: Verificar si el servicio FTP debe encontrase active 
y garantizar que los ficheros en el no tienen limitaciones de 
confidencialidad. 

VUL-02: DEFICIENCIAS EN CERTIFICADO X.509 

■ Detalle: El certificado X.509 instalado en el servicio HTTPS presenta 
deficiencias en cuanto a su longitud de clave RSA (1024), asi conno 
en cuanto a la entidad certificadora que lo emite y al CN utilizado. 

■ Riesgo: Bajo. Facilita la suplantacion del sitio a un atacante. 

■ Evidencia: 



Visor de certificados:"mir^tla'b" 


y 


General ^ get3lleS| 




No se pudo verificar este certificado porque no se confia en el emtsor. 


Emitido para 

Nombre comun (CN) ^^^^ 

Organizacion (0) <No es parte de un certificado 
Unidad organizativa (OU) <No es parte de un certificado 
Numero de serie OftAC;B3:B6:BB;54:9F;a5:63 



Emitido para 

Nombre comiin (CN) mintlab 
Organizacion (0) <No es parte de un certificado 

Unidad organizativa (OU) <No es parte de un certificado> 
Numero de serie 00:AC:B3;B6:BB;54:9F;85:63 

Emitido por 

Nombre comun (CN) mintlab 

Organizacion (0) mintlab 

Unidad organizativa (OU) <No es parte de un certificado 
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■ Recomendacion: Utilizar un certificado con longitud RSA 2048 
firmado por una CA confiable y con el CN del sistema. 

VUL-03: INDEXACION DE DIRECTORIOS 

■ Detalle: En el aplicativo Moodle se han determinado dos directorios 
indexables /moodle/lib/ajax y /moodle/repository. Esto puede 
permitir y facllltar fugas de informacion de contenidos 
erroneamente colocados en esos directorios. 

■ Riesgo: Bajo. Facilitar fugas de informacion. 

■ Recomendacion: No permitir la indexacion de directorio. 
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